why do configurations for openclaw.json copied from the documentation sometimes failing? | Friends of the Crustacean 🦞🤝 | Page 1

delicate ivy Apr 16, 2026, 7:56 PM

#

take a look at this, i'm trying to setup openclaw browser usage

  "plugins": {
    "entries": {
      browser: {
    enabled: true,
    ssrfPolicy: {
      dangerouslyAllowPrivateNetwork: true,
    },
    remoteCdpTimeoutMs: 1500,
    remoteCdpHandshakeTimeoutMs: 3000,
    defaultProfile: "openclaw",
    color: "#FF4500",
    headless: false,
    noSandbox: false,
    attachOnly: false,
    profiles: {
      openclaw: { cdpPort: 18800, color: "#FF4500" },
      work: { cdpPort: 18801, color: "#0066CC" },
      user: {
        driver: "existing-session",
        attachOnly: true,
        color: "#00AA00",
      },
      remote: { cdpUrl: "http://10.0.0.42:9222", color: "#00AA00" },
        },
      },
      "brave": {

what's the deal, i copied from the docs and it's not working.

grave whaleBOT Apr 16, 2026, 7:56 PM

#

white jettyBOT Apr 16, 2026, 7:56 PM

#

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

grave whaleBOT Apr 16, 2026, 7:56 PM

#

blissful vaporBOT Apr 16, 2026, 7:58 PM

#

first, what does openclaw --version say?

But I think I see the main problem already: you’re mixing two different config sections.

plugins.entries.browser.enabled only toggles the bundled browser plugin on/off
the actual browser runtime config belongs at top-level browser

So this is the shape you want:

{
  plugins: {
    entries: {
      browser: {
        enabled: true,
      },

#

    },
  },

  browser: {
    enabled: true,
    ssrfPolicy: {
      dangerouslyAllowPrivateNetwork: true,
    },
    remoteCdpTimeoutMs: 1500,
    remoteCdpHandshakeTimeoutMs: 3000,
    defaultProfile: "openclaw",
    color: "#FF4500",
    headless: false,
    noSandbox: false,
    attachOnly: false,

#

    profiles: {
      openclaw: { cdpPort: 18800, color: "#FF4500" },
      work: { cdpPort: 18801, color: "#0066CC" },
      user: {
        driver: "existing-session",
        attachOnly: true,
        color: "#00AA00",
      },
      remote: { cdpUrl: "http://10.0.0.42:9222", color: "#00AA00" },
    },
  },
}

A couple more gotchas:

#

if you use plugins.allow, it must include "browser"
existing-session is for a browser on the same host as the gateway, not a remote machine
after changing browser config, restart the gateway: openclaw gateway restart

Docs:

If you paste:

openclaw --version
the exact error
whether 10.0.0.42 is remote, WSL2, or same machine

…I can tell you the next fix pretty quickly.

delicate ivy Apr 16, 2026, 8:03 PM

#

okay here's how i've altered my config

  "plugins": {
    "entries": {
      browser: {
    enabled: true,
      },
      "brave": {
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": "CENSORED"
          }
        }
      },
      "ollama": {
        "enabled": true
      }
    }
  },
  "skills": {
    "install": {
      "nodeManager": "npm"
    }
  }
  browser: {
    ssrfPolicy: {
      dangerouslyAllowPrivateNetwork: true,
    },
    remoteCdpTimeoutMs: 1500,
    remoteCdpHandshakeTimeoutMs: 3000,
    defaultProfile: "openclaw",
    color: "#FF4500",
    headless: false,
    noSandbox: false,
    attachOnly: false,
    profiles: {
      openclaw: { cdpPort: 18800, color: "#FF4500" },
      work: { cdpPort: 18801, color: "#0066CC" },
      user: {
        driver: "existing-session",
        attachOnly: true,
        color: "#00AA00",
      },
      remote: { cdpUrl: "http://10.0.0.42:9222", color: "#00AA00" },
    },
  },
}

browser builtin plugin is still failing. additionally this is a windows machine

blissful vaporBOT Apr 16, 2026, 8:04 PM

#

yep, this pasted config is still broken as written.

The immediate syntax issue is here:

  "skills": {
    "install": {
      "nodeManager": "npm"
    }
  }
  browser: {

You’re missing a comma after the skills block.

OpenClaw reads openclaw.json as JSON5, so these are fine:

#

browser: { ... }
trailing commas
mixed quoted/unquoted keys

But the comma between top-level sections is still required.

Try this shape instead:

{
  plugins: {
    entries: {
      browser: {
        enabled: true,
      },
      brave: {

#

        enabled: true,
        config: {
          webSearch: {
            apiKey: "CENSORED",
          },
        },
      },
      ollama: {
        enabled: true,
      },
    },
  },

  skills: {
    install: {

#

      nodeManager: "npm",
    },
  },

  browser: {
    enabled: true,
    executablePath: "C:\\Program Files\\BraveSoftware\\Brave-Browser\\Application\\brave.exe",
    ssrfPolicy: {
      dangerouslyAllowPrivateNetwork: true,
    },
    remoteCdpTimeoutMs: 1500,
    remoteCdpHandshakeTimeoutMs: 3000,
    defaultProfile: "openclaw",
    color: "#FF4500",
    headless: false,

#

    noSandbox: false,
    attachOnly: false,
    profiles: {
      openclaw: { cdpPort: 18800, color: "#FF4500" },
      work: { cdpPort: 18801, color: "#0066CC" },
      user: {
        driver: "existing-session",
        attachOnly: true,
        color: "#00AA00",
      },
      remote: { cdpUrl: "http://10.0.0.42:9222", color: "#00AA00" },
    },
  },
}

#

A couple Windows-specific notes:

if you want the managed browser, executablePath helps a lot
if you want the live signed-in browser via user, the browser must already be open, be Chromium 144+, and have remote debugging enabled in:
- brave://inspect/#remote-debugging
- chrome://inspect/#remote-debugging
- edge://inspect/#remote-debugging

Then restart the gateway:

openclaw gateway restart

Also run:

#

openclaw --version
openclaw doctor

If it still fails, paste the exact output of:

openclaw browser --browser-profile openclaw status

or, if you’re using the live browser attach path:

openclaw browser --browser-profile user status

#

Docs:

delicate ivy Apr 16, 2026, 8:08 PM

#

it was the missing , after skills. okay. now i've barely been able to get it working any time i ask the model to use the browser through the tui it just says 'i can't do that' i'm not sure if it is a model punt or openclaw genuinely doesn't work that way. tools like browser open it seems to be unable to use

blissful vaporBOT Apr 16, 2026, 8:10 PM

#

yeah, OpenClaw does support browser use from the TUI.

If the agent says just “I can’t do that”, that’s usually one of these:

model punt
the model is weak at tool calling, or is configured in a mode that breaks tool use
tool policy block
browser is denied by tools.allow / tools.deny or per-agent policy
plugin/tool not loaded for the agent path
less likely if CLI browser commands work, but still worth checking

The big one I’m suspicious of here: Ollama / OpenAI-compatible /v1 mode.
If your Ollama config uses a base URL ending in /v1, tool calling is flaky and models often just refuse or emit junk instead of actually calling tools.

Per docs, for Ollama you want:

#

models: {
  providers: {
    ollama: {
      baseUrl: "http://127.0.0.1:11434", // no /v1
      api: "ollama",
      apiKey: "ollama-local",
    },
  },
}

Not:

baseUrl: "http://127.0.0.1:11434/v1"

#

Quick triage:

if this works:

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

then the browser runtime is fine

if the TUI still refuses, check config for:
- plugins.allow
- tools.allow
- tools.deny
- agents.defaults.tools.*
- any per-agent tools.*

Also try a very explicit prompt in TUI:

#

Use the browser tool to open https://example.com, then tell me the page title.

If it still punts, I’d bet on model/tool-calling quality, not the browser feature itself.

Paste these and I can narrow it down fast:

openclaw --version
your models.providers.ollama block, if you use Ollama
whether openclaw browser ... open https://example.com works from CLI

Docs:

For current “which models are actually good at tools” advice, also check #models plus:

https://docs.openclaw.ai/concepts/models

#

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

delicate ivy Apr 16, 2026, 8:12 PM

#

okay bnut after starting the browser how can i get the llm to actually do anything with that open browser

blissful vaporBOT Apr 16, 2026, 8:13 PM

#

there isn’t a separate “attach the LLM to this window” step.

Once the browser is started, the model has to call the browser tool during its turn. So in the TUI, ask it very explicitly.

For the managed browser:

Use the browser tool with profile openclaw to open https://example.com, then tell me the page title.

For your real logged-in browser:

Use the browser tool with profile user to inspect the currently open tab and summarize what’s on the page.

For interactive stuff:

Use the browser tool to open https://example.com, take a snapshot, and click the Sign in button.

A good pattern is:

#

open page
snapshot
act on refs from the snapshot

So if you want it to do more complex stuff, say that directly:

Use the browser tool with profile openclaw, open https://news.ycombinator.com, take a snapshot, open the top story, and summarize it.

A couple gotchas:

if you want it to use the browser you started, make sure it’s the same profile, usually openclaw
if you want the live signed-in browser, use profile="user" and keep that browser open
vague prompts like “go browse this” get punted more often than explicit tool requests

If it still says “I can’t do that” after a prompt like the above, that’s usually not normal browser behavior, it’s usually:

model/tool-calling weakness
tool policy blocking browser

#

sandbox/host-browser restriction

If you want, paste the exact TUI prompt you used plus the reply it gave, and I can tighten the wording.

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

delicate ivy Apr 16, 2026, 8:32 PM

#

my claw isn't finding the browser tool availble to it despite a browser currently running

"I don't have a browser tool available."

PS C:\Users\kmyc.openclaw\workspace> openclaw browser status

openclaw browser status

:lobster: OpenClaw 2026.4.14 (323493f) — One CLI to rule them all, and one more restart because you changed the port.

│
◇
profile: openclaw
enabled: true
running: true
transport: cdp
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800
browser: chrome
detectedBrowser: chrome
detectedPath: C:\Program Files\Google\Chrome\Application\chrome.exe
profileColor: #FF4500
PS C:\Users\kmyc\.openclaw\workspace>

so the browser is open.

blissful vaporBOT Apr 16, 2026, 8:32 PM

#

ah, nice, this narrows it down a lot.

That output means the browser runtime is fine.
What’s broken is tool exposure to the agent.

openclaw browser status proves:

browser plugin is loaded
browser service is running
Chrome/CDP is healthy

But the agent’s tool list is a separate layer.

The likely culprit is tools.profile.

Per docs, local onboarding often defaults to:

#

tools: {
  profile: "coding",
}

And coding does not include browser.
browser lives in group:ui.

So add one of these:

Option 1, keep coding profile, add browser

{
  tools: {
    profile: "coding",

#

    allow: ["group:ui"],
  },
}

or just:

{
  tools: {
    profile: "coding",
    allow: ["browser"],
  },
}

#

Option 2, full tool access

{
  tools: {
    profile: "full",
  },
}

Also check that you do not have:

tools: {
  deny: ["browser"]
}

#

or a per-agent deny under agents.defaults.tools.* / agents.list[].tools.*.

Then:

restart gateway
```
openclaw gateway restart
```
start a fresh TUI session

That last part matters, I wouldn’t trust an old session to reflect changed tool policy cleanly.

So yeah, the key point is:

browser running != browser tool exposed to the LLM

Docs:

#

If you want, paste your current tools block and I’ll tell you the exact line to add.

delicate ivy Apr 16, 2026, 9:50 PM

#

is it a limitation of this app that my openclaw browser can't download anything?

blissful vaporBOT Apr 16, 2026, 9:51 PM

#

not as a blanket limitation, no.

The important split is:

managed openclaw profile: downloads are supported
user / existing-session profile: download interception is a current limitation

The docs explicitly call out that existing-session is missing things like:

download interception
PDF export
batch actions
responsebody

So if you need the agent/app to reliably handle downloads, use the managed openclaw browser, not the live attached user browser.

OpenClaw also has download commands/hooks:

#

openclaw browser waitfordownload
openclaw browser download <ref> report.pdf

And downloads go to the OpenClaw temp downloads dir, on Windows that’s typically under your temp folder, e.g. something like:

%TEMP%\openclaw\downloads

Since your status showed:

profile: openclaw
transport: cdp
running: true

#

…then downloads should be possible there. If they’re not, that sounds more like a specific bug/flow issue than “browser downloads are unsupported”.

If you want, paste:

which profile you were using when download failed
what action triggered it
the exact error or behavior

and I can tell you if it’s expected limitation vs actual breakage.

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

delicate ivy Apr 16, 2026, 9:52 PM

#

given the context i've provided, should my openclaw browser be able to download things? i'm noticing downloads aren't appearing in my downloads folder

blissful vaporBOT Apr 16, 2026, 9:53 PM

#

given the context you posted, yes, your openclaw managed browser should be able to download things.

But the important bit is: those downloads do not go to your normal Windows Downloads folder.

Per docs, managed-browser downloads go to OpenClaw’s temp downloads directory, which on Windows is typically:

$env:TEMP\openclaw\downloads

So if you’re looking in:

C:\Users\you\Downloads

…that’s probably why it looks like nothing happened.

#

Given your earlier status showed:

profile: openclaw
running: true
transport: cdp

that means you’re on the managed path, so OpenClaw should save downloads under its own temp area, not your regular browser downloads folder.

Quick check in PowerShell:

Get-ChildItem "$env:TEMP\openclaw\downloads"

So the short answer is:

should it download? yes

#

should it appear in your normal Downloads folder? no, not by default

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

If you want, I can help you test one known-good download flow next.

delicate ivy Apr 16, 2026, 9:55 PM

#

in wsl how can i access the windows $env:TEMP dir

blissful vaporBOT Apr 16, 2026, 9:56 PM

#

in WSL, Windows temp is usually mounted under:

/mnt/c/Users/<your-windows-user>/AppData/Local/Temp

So for your case it’s probably:

/mnt/c/Users/kmyc/AppData/Local/Temp/openclaw/downloads

Quick check:

ls /mnt/c/Users/kmyc/AppData/Local/Temp/openclaw/downloads

#

If you want to ask Windows for the exact %TEMP% and convert it to a WSL path:

WIN_TEMP=$(cmd.exe /C "echo %TEMP%" | tr -d '\r')
wslpath "$WIN_TEMP"

That’ll print the exact WSL path to the Windows temp dir.

delicate ivy Apr 16, 2026, 10:01 PM

#

is it possible that the downloads from this builtin browser plugin are located elsewhere since i'm running this gateway on windows? i was able to find the temp dir/openclaw/ but all that's in there is a gateway lock and log file

blissful vaporBOT Apr 16, 2026, 10:02 PM

#

yeah, very possible, and I think you checked one level too high.

For the managed browser, the docs path is:

%TEMP%\openclaw\downloads

not just:

%TEMP%\openclaw

So on Windows, I’d check:

#

Get-ChildItem "$env:TEMP\openclaw\downloads"

or recursively:

Get-ChildItem "$env:TEMP\openclaw" -Recurse

Given your earlier openclaw browser status showed profile: openclaw, a successful managed-browser download should land in that downloads subfolder, not your normal Downloads folder.

If that subfolder doesn’t exist at all, then the likely explanations are:

no actual OpenClaw-managed download happened yet
the click/navigation didn’t trigger a captured download event
you were effectively on a different path/profile when testing

#

So: yes, they may be elsewhere, but they should still be under the Windows temp tree, specifically openclaw\downloads.

If you check that exact folder and it’s still empty, then I’d start treating it as a browser-download flow issue, not “expected location confusion.”

delicate ivy Apr 16, 2026, 10:07 PM

#

okay using my brain i found the download here, how queer

./Users/kmyc/AppData/Local/Temp/playwright-artifacts-kUPMEW/91b2c74d-ac37-409e-a957-6ea4518ec652

blissful vaporBOT Apr 16, 2026, 10:08 PM

#

hah, yeah, that path looks like a Playwright temp artifacts dir, not the cleaner OpenClaw downloads folder the docs imply.

So the practical answer is:

your download did happen
on your setup it landed in a Playwright temp path
that’s why it didn’t show up in Downloads or the openclaw/downloads path you were expecting

Given your earlier status and this path, I’d call that a docs mismatch or bug-shaped behavior on Windows, not you doing something wrong.

If it keeps reproducing, I’d report it as:

OpenClaw 2026.4.14
Windows gateway
managed openclaw browser profile
expected: OpenClaw temp downloads dir
actual: ...AppData/Local/Temp/playwright-artifacts-...

#why do configurations for openclaw.json copied from the documentation sometimes failing?

Option 1, keep coding profile, add browser

Option 2, full tool access