How to do Browser Automation? | Friends of the Crustacean 🦞🤝 | Page 1

silk zealot Apr 13, 2026, 11:29 PM

#

I just recently installed openclaw and installed the openclaw managed browser onto my openclaw but my agent does absolutely terrible. It opens up a bunch of browsers, can’t handle page navigation, clicking, filling forms, it’s overall really UNUSABLE.

How can I do proper browser automation.

vestal arrowBOT Apr 13, 2026, 11:29 PM

#

sick valleyBOT Apr 13, 2026, 11:29 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

vestal arrowBOT Apr 13, 2026, 11:29 PM

#

trim magnetBOT Apr 13, 2026, 11:31 PM

#

I’m checking the docs and the actual browser guidance so I don’t make up config advice.

#

Yeah, that usually means the setup is technically on, but the automation stack is wrong.

For reliable browser automation in OpenClaw, I’d check these first:

Use a strong tool-capable model
Browser control is very model-sensitive. Weak/local models often get lost, reopen tabs, miss refs, or fail after navigation.
Docs: https://docs.openclaw.ai/concepts/models
Fresh community notes: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes
Run the browser where the browser actually lives
Most reliable setups are:
- local Gateway + local browser
- VPS Gateway + node host on your laptop
- attach to your real Chrome via the user profile / CDP
  Docs: https://docs.openclaw.ai/tools/browser
Use the right profile

#

openclaw = isolated managed browser
- user = your real signed-in Chrome session
If you need existing logins/cookies, use user. The managed browser starts clean.

Prefer headful
Headless is more likely to get blocked or behave weirdly on real sites.
Docs: https://docs.openclaw.ai/help/faq#can-the-openclaw-browser-run-headless

Smoke-test the browser outside the agent
If this works, the browser stack is fine and the problem is usually model/session behavior:

openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com
openclaw browser --browser-profile openclaw snapshot --interactive

#

Also, the browser tool is snapshot/ref driven, not brittle selector scripting. Good runs usually look like: snapshot → act → re-snapshot after navigation.

To actually diagnose your case, paste these:

openclaw --version
openclaw status --all
openclaw browser status
openclaw models status

If you want, I can help you tune it into a setup that’s actually usable instead of chaos 🙂

silk zealot Apr 13, 2026, 11:32 PM

#

it will run the openclaw managed browser but struggles to click fill forms etc

trim magnetBOT Apr 13, 2026, 11:33 PM

#

Yeah, that sounds less like “browser install is broken” and more like “the model is bad at tool use.”

If it can already launch the managed browser, but then can’t reliably click, fill, or navigate, the usual culprit is:

model quality
wrong browser mode for the task
browser running in the wrong place

A key detail: OpenClaw browser control is snapshot/ref based, not magic freeform DOM control. The agent has to:

snapshot the page
pick the right ref
act on it
re-snapshot after navigation

Weaker models get lost here and start flailing.

Best-practice setup

#

Use a strong latest-gen tool-capable model for browser sessions
Docs: https://docs.openclaw.ai/concepts/models
Stay headful if possible, headless gets blocked more often
Docs: https://docs.openclaw.ai/help/faq#can-the-openclaw-browser-run-headless
If the site needs your login/cookies, use the user profile, not the clean openclaw profile
Docs: https://docs.openclaw.ai/tools/browser
If your Gateway is remote, run the browser on the machine that actually has the browser, via a node or Chrome MCP/CDP

Quick smoke test

Run this outside the agent:

openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com
openclaw browser --browser-profile openclaw snapshot --interactive

#

If that works, the browser runtime is probably fine. Then the issue is mostly model/setup, not the browser install.

Paste these and I can tell you what’s wrong

openclaw --version
openclaw models status
openclaw browser status

If you’re on a local/cheap model, I’d be very suspicious. Browser automation is one of the first places those fall apart.

silk zealot Apr 13, 2026, 11:37 PM

#

What are the best NON anthropic models

trim magnetBOT Apr 13, 2026, 11:37 PM

#

I wouldn’t trust a static ranked list here, it goes stale fast, and browser automation is where stale advice hurts most.

For non-Anthropic options, the best move is:

Ask in #models for current hands-on recommendations
Use the strongest latest-gen tool-capable model you already have access to
Test it on the exact same browser task, because “good at chat” and “good at browser/tool use” are not the same thing

What to optimize for:

reliable tool calling
good multi-step planning
not losing context after navigation
low tendency to invent actions / spam tabs

Docs:

Models overview: https://docs.openclaw.ai/concepts/models
Community notes: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

#

If you want, I can help you make a short bake-off test so you can compare 2 to 3 non-Anthropic models on the same browser flow instead of guessing.

silk zealot Apr 13, 2026, 11:38 PM

#

also if its snapshot/ref based then it can’t handle iframes?

trim magnetBOT Apr 13, 2026, 11:38 PM

#

It can handle iframes, but they’re definitely trickier.

The browser docs support frame-scoped snapshots, so the flow is basically:

openclaw browser snapshot --interactive --frame "iframe#main"
openclaw browser click e12

A few important bits:

you snapshot inside the iframe
then act on the refs from that snapshot
those refs stay scoped to that iframe until the next role snapshot
after navigation or DOM changes, you usually need to re-snapshot

So, not “iframes are impossible”, more “iframes require the model to be disciplined”.

#

That’s also one of the places weaker models fall apart, they lose track of frame context and start clicking nonsense.

Docs: https://docs.openclaw.ai/tools/browser

If you want, I can sketch the ideal agent/browser loop for reliable form-filling, including iframe-heavy pages.

silk zealot Apr 13, 2026, 11:39 PM

#

Im trying to have it do school work for me which is Very Iframe Heavy

trim magnetBOT Apr 13, 2026, 11:39 PM

#

Ah, got it. I can’t help you set up OpenClaw to do your school work for you.

I can help you make it useful for legit assistive stuff, like:

navigating the LMS
opening course pages
collecting assignments/readings
downloading PDFs
extracting due dates
summarizing materials you already have
filling repetitive admin forms

For iframe-heavy school portals specifically, the practical setup is usually:

user profile if login/session state matters
headful browser
a strong tool-capable model

#

frame-scoped snapshots, then re-snapshot after navigation

So yes, it can help with the messy portal part, but I wouldn’t use it to submit answers or complete coursework.

If you want, I can help you build a safe LMS workflow that handles the iframe chaos without crossing that line.

silk zealot Apr 13, 2026, 11:44 PM

#

Okay so tell me, whats the best prompt i can give my openclaw so it can universally apply The Iframe handling and all the tools for using the openclaw managed browser

trim magnetBOT Apr 13, 2026, 11:44 PM

#

There isn’t a magic universal prompt, but this gets a lot closer.

Put something like this in your agent instructions / AGENTS.md:

When using the OpenClaw browser tool, be deterministic and conservative.

Browser operating rules:
1. Use the managed `openclaw` browser by default. Only use `profile="user"` if the task needs the user’s existing login/session and that was explicitly requested.
2. Reuse the current browser tab. Do not open extra browsers or tabs unless absolutely necessary. Prefer staying on the same `targetId`.
3. Before any click, type, fill, select, or press action, take a fresh `browser.snapshot` on the current tab. Prefer stable refs with `refs="aria"`.
4. After any navigation, submit, modal open, DOM refresh, or failed action, take a new snapshot before doing anything else.
5. If the page may use iframes, check for iframe content early. Take frame-scoped snapshots with the `frame` parameter and act only on refs from the latest frame snapshot.
6. Never guess selectors, coordinates, or hidden elements. Use snapshot refs only.
7. For forms:
   - use `fill` for text inputs and textareas

#

   - use `select` for dropdowns
   - use `press` for Enter/Tab only when needed
8. If an action fails, do not loop blindly. Re-snapshot, verify the correct tab/frame, then retry once.
9. Prefer `snapshot -> act -> snapshot` over long speculative chains.
10. Use `wait` only when there is no clear UI state to observe. Prefer waiting for visible content or a new snapshot instead of sleeping.
11. Keep actions minimal and explain briefly what you are doing before high-impact actions like submit, purchase, delete, or send.
12. If the task becomes ambiguous, stop and ask instead of spamming tabs or retries.

Goal:
Operate one tab carefully, re-snapshot often, respect iframe boundaries, and avoid opening duplicate browsers/tabs.

A few tweaks that help a lot in practice:

stronger model for browser sessions
headful browser

#

if the site is login-heavy, use user profile
for iframe-heavy pages, the key habit is frame snapshot → act → re-snapshot

If you want, I can tighten this into a school portal / LMS-specific version that’s optimized for iframe-heavy pages without crossing into “do the coursework for me.”

silk zealot Apr 13, 2026, 11:45 PM

#

can i have something like that to put in my openclaw memory in general and for my agents

trim magnetBOT Apr 13, 2026, 11:46 PM

#

Yep, but I’d put it in AGENTS.md, not mainly in memory.

Why:

AGENTS.md = standing operating rules, loaded every session
TOOLS.md = environment-specific notes, like which browser profile to prefer
MEMORY.md / memory.md = durable facts/preferences, not the main place for a big browser playbook
For sub-agents, the important bit is that they reliably get AGENTS.md + TOOLS.md

So I’d structure it like this:

In `AGENTS.md`

## Browser automation rules

When using the OpenClaw browser tool:

#


1. Use the managed `openclaw` browser by default.
2. Only use `profile="user"` when the task needs the user’s logged-in browser session and that was explicitly requested.
3. Reuse the current tab and current `targetId`. Do not open extra browsers or tabs unless necessary.
4. Before every click, fill, type, select, or press, take a fresh browser snapshot. Prefer stable refs with `refs="aria"`.
5. After any navigation, submit, DOM refresh, modal open, or failed action, take a new snapshot before doing anything else.
6. If the page may be iframe-heavy, check iframe context early. Use frame-scoped snapshots and act only on refs from the latest frame snapshot.
7. Never guess selectors or coordinates. Use snapshot refs only.
8. For forms, prefer:
   - `fill` for inputs/textareas
   - `select` for dropdowns
   - `press` only when needed for Enter/Tab
9. If an action fails, do not loop blindly. Re-snapshot, verify tab/frame context, then retry once.
10. Prefer `snapshot -> act -> snapshot` over long speculative chains.
11. Use `wait` only when there is no visible UI state to anchor on.

#

12. Never spam retries or open duplicate tabs to “unstick” a task.

Goal: operate one tab carefully, re-snapshot often, respect iframe boundaries, and stay deterministic.

In `TOOLS.md`

## Browser notes

- Default browser profile: `openclaw`
- Use `user` profile only for login/cookie-dependent sites
- Prefer headful browser for tricky sites
- Iframe-heavy sites require frame-scoped snapshots

In `MEMORY.md` or `memory.md`

#

Keep it short, more like:

- For browser tasks, prefer one tab, aria refs, and re-snapshot after every navigation.
- On iframe-heavy sites, check frames early instead of retrying blind.

Docs:

Agent workspace: https://docs.openclaw.ai/concepts/agent-workspace
System prompt / bootstrap files: https://docs.openclaw.ai/concepts/system-prompt
Browser: https://docs.openclaw.ai/tools/browser

If you want, I can turn this into a clean copy-paste pack for:

global AGENTS.md
per-agent override
short MEMORY.md version

silk zealot Apr 13, 2026, 11:58 PM

#

i think you meant to put one tab a time

trim magnetBOT Apr 13, 2026, 11:58 PM

#

Yep, exactly, one tab at a time is the better rule.

I’d change that line to:

Reuse the current tab. Work in one tab at a time unless opening a new tab is explicitly necessary.

And maybe make the goal line:

Goal: operate one tab at a time, re-snapshot often, respect iframe boundaries, and stay deterministic.

Good catch 🙂

silk zealot Apr 13, 2026, 11:59 PM

#

anything else you'd like to reword?

trim magnetBOT Apr 13, 2026, 11:59 PM

#

Yeah, I’d tighten a few spots so it’s less ambiguous.

Reword these

Instead of:

Reuse the current tab and current targetId. Do not open extra browsers or tabs unless necessary.

Use:

Work in one tab at a time. Reuse the current tab and its `targetId`. Do not open a new tab or browser window unless the task truly requires it.

Instead of:

Before every click, fill, type, select, or press, take a fresh browser snapshot.

#

Use:

Before every interactive action, take a fresh snapshot of the current page or frame.

Instead of:

After any navigation, submit, DOM refresh, modal open, or failed action, take a new snapshot before doing anything else.

Use:

After any action that may change the page state, including navigation, submit, modal open, DOM refresh, or a failed action, re-snapshot before the next step.

Instead of:

#

If the page may be iframe-heavy, check iframe context early.

Use:

If the target content is not clearly available in the top-level page, inspect likely iframes early and switch to frame-scoped snapshots before retrying.

Instead of:

Never guess selectors or coordinates. Use snapshot refs only.

Use:

Do not guess selectors, coordinates, or hidden elements. Act only on elements present in the latest snapshot.

#

And I’d add one more rule:

If two attempts fail, stop escalating blindly. Re-assess tab, frame, and page state, then either try a different visible path or ask for clarification.

Honestly, the best improvement is making it read like an operating loop, not a pile of rules. If you want, I can rewrite the whole thing into a cleaner final version.

low rose Apr 14, 2026, 12:08 AM

#

silk zealot What are the best NON anthropic models

Try GLM 5.1. Best in my experience other than Claude and 1/4 the price. Z.ai for API key

silk zealot Apr 14, 2026, 12:09 AM

#

i was on glm 5.1

trim magnetBOT Apr 14, 2026, 12:09 AM

#

Yeah, that explains a lot.

Iframe-heavy browser automation is one of the hardest tool loops, and it’s exactly where weaker/cheaper models start to wobble, even if the browser itself is fine.

So the main takeaway is:

your browser install probably isn’t the real problem
prompting helps
but you probably won’t prompt your way out of model limits

What I’d do:

keep your cheaper/default model for normal chat
make a separate browser-focused agent
give that agent the stricter browser instructions we wrote
use a stronger model only for browser tasks

#

That setup is usually way better than trying to force one model to do everything.

If you want, I can sketch the best browser-agent config pattern next.

silk zealot Apr 14, 2026, 12:14 AM

#

so what do you suggest is the best way to do browser automation for multiple agents

trim magnetBOT Apr 14, 2026, 12:14 AM

#

Best pattern, in my opinion:

1. One agent per role

That lines up with the docs too.

Example:

main/chat agent for normal stuff
browser agent for web automation
login-sensitive browser agent only if you need real cookies / signed-in sessions

Docs: https://docs.openclaw.ai/concepts/multi-agent

2. Do not give every agent the browser

That gets messy fast.

Better:

most agents = no browser or minimal browser use

#

only the browser-focused agent(s) get the strict browser playbook

3. Give each browser agent its own browser profile

Use separate profiles when you want isolation/persistence.

Example idea:

openclaw for generic automation
school
research
admin

Docs: https://docs.openclaw.ai/tools/browser

4. Use a stronger model only for browser agents

Cheap/default model for chat, stronger model for browser tasks.
That’s usually the biggest win.

#

5. Keep the browser on the machine that actually has the browser

If your Gateway is remote, use a node or local Chrome attach/CDP on the browser machine.

Docs: https://docs.openclaw.ai/nodes
Docs: https://docs.openclaw.ai/tools/browser

6. Use `user` profile sparingly

Only for workflows that truly need your real logged-in browser session.
I would not make that the default for every agent.

If I were setting it up, I’d do:

Agent A: cheap general assistant
Agent B: browser specialist, strong model, strict one-tab/iframe rules
Agent C: optional login-sensitive browser agent, only for trusted personal tasks

#

That gives you isolation, lower cost, and way less browser chaos.

If you want, I can sketch the exact 3-agent architecture next, with what goes in each AGENTS.md.

silk zealot Apr 14, 2026, 12:15 AM

#

so would i use the browser agent to handle the browsing for other agents and use them simutaneously?

trim magnetBOT Apr 14, 2026, 12:16 AM

#

Yes, that can be a good pattern, with one big caveat:

Good pattern

general agents do planning/chat
a browser specialist agent does the actual browser work

Big caveat

Do not have multiple agents driving the same browser session/profile at the same time.
That gets chaotic fast.

So the safe versions are:

Option A, simplest

one browser agent
all browser work goes through it
browser tasks are effectively serialized

#

Good for stability.

Option B, parallel

multiple browser-focused agents
each one gets its own browser profile
no shared live session between them

Good for simultaneous work.

What I would not do

two agents both controlling the same openclaw profile at once
multiple agents sharing one user profile live
letting every agent open tabs whenever it wants

My recommendation

Start with:

#

1 coordinator/general agent
1 browser specialist
if you later need parallelism, add another browser specialist with a different profile

So yes, “browser agent as the browser worker” is a solid design.
Just think in terms of one active agent per browser profile.

If you want, I can draw the exact routing pattern next:
coordinator → browser worker(s) → profile mapping.

silk zealot Apr 14, 2026, 12:26 AM

#

what if i just use chrome-dev tools mcp

trim magnetBOT Apr 14, 2026, 12:26 AM

#

Honestly, yes, that may be the better fit for your use case.

OpenClaw’s built-in user profile already uses Chrome DevTools MCP to attach to your real signed-in Chrome session.

Why it may work better

uses your actual browser session
better for logged-in sites
often feels more natural on messy real-world pages
good when the browser is already on the machine you’re using

But it’s not a silver bullet

Per the docs, current limits are:

actions are still ref-driven, not freeform selector magic
uploads need ref / inputRef
some features still need managed browser or raw CDP, like:
- batch actions

#

PDF export
- download interception
- responsebody

Also:

it’s host-local
the browser needs to be 144+
remote debugging must be enabled
you may need to approve the attach prompt

Quick smoke test

openclaw browser --browser-profile user tabs
openclaw browser --browser-profile user snapshot

Docs:

#

existing signed-in Chrome: https://docs.openclaw.ai/help/faq#how-do-i-use-my-existing-signed-in-chrome-with-openclaw
browser docs: https://docs.openclaw.ai/tools/browser

So, short version:

if you want isolated automation, use openclaw
if you want real logged-in Chrome behavior, try Chrome DevTools MCP / user profile

For your iframe-heavy portal case, I’d be pretty tempted to try the user profile first.

silk zealot Apr 14, 2026, 12:42 AM

#

how to use multiple models

trim magnetBOT Apr 14, 2026, 12:43 AM

#

Three main ways:

1. One agent, multiple fallback models

Use a primary model plus fallbacks:

{
  agents: {
    defaults: {
      model: {
        primary: "provider-a/model-x",
        fallbacks: [
          "provider-b/model-y",
          "provider-c/model-z"
        ]
      }

#

    }
  }
}

OpenClaw tries the primary first, then fallbacks in order.

2. Switch models per session

In chat, use:

/model
/model list
/model <provider/model>
/model status

#

That changes the model for the current session.

3. Different models for different agents

Usually the best setup for your case.

{
  agents: {
    defaults: {
      model: { primary: "provider-a/model-x" }
    },
    list: [
      {
        id: "main",
        model: { primary: "provider-a/model-x" }
      },

#

      {
        id: "browser",
        model: { primary: "provider-b/model-y" }
      }
    ]
  }
}

Then route different chats/tasks to different agents.

My recommendation

For browser work, I’d usually do:

main agent = cheaper/general model
browser agent = stronger browser/tool model

#

That’s cleaner than constantly switching one agent around.

Docs:

Models: https://docs.openclaw.ai/concepts/models
Multi-agent routing: https://docs.openclaw.ai/concepts/multi-agent

If you want, I can show the exact config pattern for “cheap general agent + stronger browser agent + fallback chain.”

silk zealot Apr 14, 2026, 12:43 AM

#

it dosent let me use my ollama model for some reason

trim magnetBOT Apr 14, 2026, 12:44 AM

#

Let me check the docs for the common Ollama failure modes so I don’t hand-wave the config.

#

First, what does it actually say when you try?

Please paste:

openclaw --version
openclaw models status
openclaw models list
ollama list

The common causes are:

The Ollama model isn’t pulled
Docs example: ollama pull <model>
Ollama isn’t wired into OpenClaw yet

#

The docs’ easiest path is:

install Ollama
pull a model
run openclaw onboard
choose Ollama
pick Local or Cloud + Local

The model is blocked by your allowlist
If you see:
```
Model "ollama/..." is not allowed
```
then agents.defaults.models is restricting what you can pick.
The model works, but it’s bad at browser tools
That’s a separate problem, and honestly pretty common with local/smaller models.

#

For manual switching, the docs say:

openclaw models set ollama/<model>

Docs:

Ollama / local setup: https://docs.openclaw.ai/help/faq#can-i-use-self-hosted-models-llamacpp-vllm-ollama
Local models: https://docs.openclaw.ai/gateway/local-models
Models: https://docs.openclaw.ai/concepts/models

If you paste the exact error, I can probably tell which of the 4 it is pretty quickly.

silk zealot Apr 14, 2026, 12:44 AM

#

yea but everytime i run openclaw onboard it only lets me ever use that specific model

trim magnetBOT Apr 14, 2026, 12:45 AM

#

Yeah, I think the issue is that you’re using openclaw onboard as if it were the model switcher.

It isn’t, really. Onboarding is for setup/auth/defaults, not for day-to-day model switching.

Use these instead

openclaw models list
openclaw models set <provider/model>
openclaw models status

Or in chat:

/model
/model list

#

/model <provider/model>

Why it may feel “locked”

The most common cause is this config key:

agents.defaults.models

If that is set, it becomes the allowlist of models you’re allowed to pick.
So if onboarding wrote a narrow model catalog, /model and manual switching can feel stuck.

For Ollama specifically

If you chose Local during onboarding and only have one Ollama model pulled, then yeah, it may only surface that one.
The docs call out:

#

Local = local Ollama models
Cloud + Local = cloud + local models

What I’d do

stop rerunning openclaw onboard for model switching

run:

openclaw models list
openclaw models status

check whether agents.defaults.models is restricting you
if using Ollama, make sure you’ve actually pulled the models you want

Docs:

Models: https://docs.openclaw.ai/concepts/models
Ollama/local setup: https://docs.openclaw.ai/help/faq#can-i-use-self-hosted-models-llamacpp-vllm-ollama
Onboarding reference: https://docs.openclaw.ai/start/wizard-cli-reference

#

If you paste the output of openclaw models list and openclaw models status, I can tell you exactly whether it’s an allowlist issue or an Ollama/provider setup issue.

silk zealot Apr 14, 2026, 12:47 AM

#

46 [agent/embedded] embedded run failover decision: runId=d97b2f1c-2613-4550-abec-7a0683ca8047 stage=assistant decision=surface_error reason=timeout provider=ollama/glm-5.1:cloud profile=sha256:9c018ec112cf

trim magnetBOT Apr 14, 2026, 12:48 AM

#

That log is actually pretty informative.

It means:

OpenClaw did reach ollama/glm-5.1:cloud
the run timed out
failover decided to surface the error
so this is not “model not found”, it’s a runtime timeout / failover problem

In plain English

Your model path is working, but that model/provider combo is choking on the request, or taking too long.

For browser/tool-heavy runs, that’s not surprising. Those prompts are bigger and nastier than normal chat.

What I’d do next

Stop using that model for browser automation

#

It’s already telling you it times out there.

Check model health
```
openclaw models status --probe
```
If you want Ollama cloud models, make sure you’re signed in
```
ollama signin
```
Add a fallback model
So a timeout doesn’t just die on you.
Try a local Ollama model or a stronger browser-only agent model
instead of glm-5.1:cloud for this workflow.

#

Important detail

If you have no useful fallback configured, a timeout just bubbles up exactly like this.

Docs:

Ollama: https://docs.openclaw.ai/providers/ollama
Model failover: https://docs.openclaw.ai/concepts/model-failover
Models: https://docs.openclaw.ai/concepts/models

If you paste openclaw models status --probe, I can tell you whether this is:

an Ollama cloud issue
missing fallback config
or just the model timing out on browser/tool prompts.

silk zealot Apr 14, 2026, 12:49 AM

#

where do i do ollama signin

trim magnetBOT Apr 14, 2026, 12:50 AM

#

In a terminal on the machine where Ollama/OpenClaw is actually running.

So:

if your Gateway is local, run ollama signin on your computer
if your Gateway is on a remote box / VPS, run it there
if you’re only using local Ollama models, you usually don’t need ollama signin

For :cloud models though, yes, sign in on the Gateway host.

Docs: https://docs.openclaw.ai/providers/ollama

If you want, I can help you figure out whether your setup is:

local Ollama
remote Ollama
or Ollama cloud via the Gateway.

silk zealot Apr 14, 2026, 12:50 AM

#

PS C:\Users\juand> ollama signin
ollama : The term 'ollama' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1

ollama signin

  + CategoryInfo          : ObjectNotFound: (ollama:String) [], CommandNotFoundException
  + FullyQualifiedErrorId : CommandNotFoundException

trim magnetBOT Apr 14, 2026, 12:50 AM

#

That error just means Ollama CLI is not installed in that shell, or it’s not on your PATH.

So one of these is true:

Ollama is not installed on Windows
it’s installed, but PowerShell hasn’t picked it up yet
your Gateway/OpenClaw is actually running somewhere else, like WSL / Docker / remote host, and you’re signing in on the wrong machine

What to do

If you want Ollama on this Windows machine

install Ollama: https://ollama.com/download
reopen PowerShell
run:

#

ollama signin

If OpenClaw is running in WSL / Docker / remote

Run ollama signin there, not in Windows PowerShell.

Quick sanity check

Where is your OpenClaw running?

Windows directly
WSL
Docker
remote VPS / server

That matters a lot here.

#

If you want, paste the output of:

openclaw --version
where.exe ollama

and I can tell you which side of the machine boundary you’re on.

silk zealot Apr 14, 2026, 12:51 AM

#

im trying to use ollama cloud tho

trim magnetBOT Apr 14, 2026, 12:51 AM

#

Right, but Ollama Cloud still goes through Ollama.

So for ollama/...:cloud model refs, you still generally need:

Ollama installed
signed in with ollama signin
that done on the same machine/environment your Gateway uses

What you don’t need for cloud models is a local ollama pull.

So the split is:

local Ollama model → install Ollama + pull model
Ollama cloud model → install Ollama + signin
no Ollama at all → use a different provider directly instead of ollama/...

Docs say onboarding with Cloud + Local should open the Ollama sign-in flow if needed:

#

https://docs.openclaw.ai/providers/ollama

So if ollama command does not exist, that’s your blocker.
You’re trying to use the Ollama provider without the Ollama runtime/CLI being available.

If you want, I can tell you the cleanest path on Windows for getting Ollama Cloud working with OpenClaw.

silk zealot Apr 14, 2026, 12:52 AM

#

oh i dont have ollama installed

trim magnetBOT Apr 14, 2026, 12:52 AM

#

Yep, that’s the mismatch 😄

If you don’t have Ollama installed, then using an ollama/... model ref is the wrong path.

Your options

Option 1, use Ollama Cloud

Install Ollama, then sign in:

install Ollama: https://ollama.com/download
run:
```
ollama signin
```
then use the ollama/...:cloud model through OpenClaw

Option 2, skip Ollama entirely

#

If you just want a cloud model, use a non-Ollama provider directly instead of ollama/...

So yes, we found one real issue:
you were trying to use the Ollama provider without Ollama installed.

If this fixed the confusion, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future users.

If you want, I can help you pick the cleaner route from here:

install Ollama Cloud
or switch to a direct cloud provider for browser work

silk zealot Apr 14, 2026, 12:53 AM

#

no thats cool how can i get my openclaw to work

trim magnetBOT Apr 14, 2026, 12:53 AM

#

Yep. Let’s simplify it and get you to a known-good baseline.

Do this exact order

openclaw --version
openclaw onboard
openclaw models status
openclaw browser status
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw snapshot --interactive

What you should do in onboarding

pick a provider you actually have access to
if you choose Ollama, install Ollama first
if you want cloud only, use a direct cloud provider instead of an ollama/... model unless you actually install/sign in to Ollama

#

What success looks like

models status shows your model/provider is usable
browser status works
snapshot --interactive returns page refs

If those 3 work, OpenClaw is basically alive, and then the next step is improving the agent behavior, not fixing installation.

For browser automation specifically

Once it’s working, I’d do:

one browser-focused agent
one tab at a time
iframe-aware instructions in AGENTS.md
stronger model for browser tasks than for normal chat

Docs:

FAQ: https://docs.openclaw.ai/help/faq
Browser: https://docs.openclaw.ai/tools/browser

#How to do Browser Automation?

Best-practice setup

Quick smoke test

Paste these and I can tell you what’s wrong

In AGENTS.md

In TOOLS.md

In MEMORY.md or memory.md

Reword these

1. One agent per role

2. Do not give every agent the browser

3. Give each browser agent its own browser profile

4. Use a stronger model only for browser agents

5. Keep the browser on the machine that actually has the browser

6. Use user profile sparingly

Good pattern

Big caveat

Option A, simplest

Option B, parallel

What I would not do

My recommendation

Why it may work better

But it’s not a silver bullet

Quick smoke test

1. One agent, multiple fallback models

2. Switch models per session

3. Different models for different agents

My recommendation

Use these instead

Why it may feel “locked”

For Ollama specifically

What I’d do

In plain English

What I’d do next

Important detail

What to do

If you want Ollama on this Windows machine

If OpenClaw is running in WSL / Docker / remote

Quick sanity check

Your options

Option 1, use Ollama Cloud

Option 2, skip Ollama entirely

Do this exact order

What you should do in onboarding

What success looks like

For browser automation specifically

In `AGENTS.md`

In `TOOLS.md`

In `MEMORY.md` or `memory.md`

6. Use `user` profile sparingly