browser issue (Chromium snapshot but 'rootwebarea' keep showing)

[plain hare]

In my CLI openclaw browser --browser-profile user snapshot --interactive still sees the full DOM (you pasted refs like [ref=1_22] for “My Request”).

• But my in‑chat browser tool only gets:

  - rootwebarea "Website"
  

  or just - rootwebarea on voucher pages.

Yesterday, the in‑chat agent’s browser tool returned full DOM for Shopee pages; today it only shows - rootwebarea, while openclaw browser --browser-profile user snapshot --interactive still returns the full DOM. Looks like the agent’s browser tool is hitting a different or degraded snapshot path.

Can anyone tell me what to do on yesterday my openclaw skill about browser automation still working but not for today?

[compact crane]

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

[wise matrix]

Let me check the browser docs and the current behavior difference between CLI and in-chat, because this smells like the tool is not actually attaching to the same browser/profile.

This probably is not the browser breaking. It looks like your chat run is using a different browser mode than your CLI test.

Most likely difference:

• CLI: openclaw browser --browser-profile user snapshot --interactive
• in-chat tool: usually defaults to the isolated openclaw profile unless the agent explicitly asks for profile="user"

So if the page needs your signed-in browser session, chat may only see rootwebarea.

Please check these first:

openclaw --version
openclaw browser --browser-profile user status
openclaw browser --browser-profile user tabs
openclaw logs --follow

Then in chat, tell the agent explicitly:

use profile="user" on the host browser, take snapshot with interactive=true, and keep the same tab/targetId for follow-up actions

If that fixes it, the issue is the tool call/prompt, not the browser runtime.

Optional, if you always want chat to use your real browser, set browser.defaultProfile: "user" (higher risk, since that is your signed-in browser).

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

If you paste openclaw --version plus the bad run log lines, I can narrow it down further.

[plain hare]

openclaw version = OpenClaw 2026.4.4 (559e42b)

[wise matrix]

I’m going to check whether 2026.4.4 has a known browser snapshot difference between CLI and the in-chat tool path, because your version info helps narrow that down a lot.

Thanks, that version helps.

I don’t see a docs-known 2026.4.4 regression that cleanly explains this by itself. The more likely issue is that the in-chat agent is not using the same browser path as your CLI.

Most likely what is happening:

• your CLI explicitly does --browser-profile user snapshot --interactive
• the in-chat browser tool is falling back to the default path, often openclaw, and in sandboxed/thread sessions it can default to the sandbox browser
• Discord/thread sessions count as non-main sessions, so if you use agents.defaults.sandbox.mode: "non-main", browser calls from chat are sandboxed unless the agent explicitly targets host control

That would explain:

• CLI on profile=user still sees full DOM
• in-chat only sees rootwebarea

What I’d do:

1. In your skill/instructions, make it explicit:

• use target="host"
  • use profile="user"
  • first call snapshot with interactive=true
  • keep the same targetId for follow-up actions

2. If your agent is sandboxed, enable host browser control:

{
  agents: {
    defaults: {
      sandbox: {
        browser: {
          allowHostControl: true,
        },
      },

    },
  },
}

3. Check these values:

openclaw config get agents.defaults.sandbox
openclaw config get browser.defaultProfile
openclaw logs --follow

If you want the chat/browser path to behave more like your CLI by default, you can also set:

{
  browser: {
    defaultProfile: "user"
  }
}

I would still prefer fixing the skill prompt first, because defaultProfile: "user" makes the agent touch your real signed-in browser by default.

Relevant docs:
https://docs.openclaw.ai/tools/browser
https://docs.openclaw.ai/tools/browser-login
https://docs.openclaw.ai/gateway/sandboxing

If you paste the output of openclaw config get agents.defaults.sandbox and openclaw config get browser.defaultProfile, I can tell you which of these is the real culprit.

[plain hare]

"browser": {
"defaultProfile": "user",
"snapshotDefaults": {
"mode": "efficient"
},

"sandbox": {
"browser": {
"allowHostControl": true
}
}

[plain hare]

output of openclaw config get agents.defaults.sandbox and openclaw config get browser.defaultProfile
'
🦞 OpenClaw 2026.4.4 (559e42b) — Somewhere between 'hello world' and 'oh god what have I built.'

{
"browser": {
"allowHostControl": true
}
}'

and

'
🦞 OpenClaw 2026.4.4 (559e42b) — Hot reload for config, cold sweat for deploys.

user'

[plain hare]

output of openclaw config get agents.defaults.sandbox and openclaw config get browser.defaultProfile
'
🦞 OpenClaw 2026.4.4 (559e42b) — Somewhere between 'hello world' and 'oh god what have I built.'

{
"browser": {
"allowHostControl": true
}
}'

and

'
🦞 OpenClaw 2026.4.4 (559e42b) — Hot reload for config, cold sweat for deploys.

user'

[wise matrix]

Nice, that narrows it down a lot.

Since:

• browser.defaultProfile is already user
• allowHostControl is already true

this no longer looks like a profile-routing problem.

The most likely issue now is snapshot mode, not browser/profile selection.

What I suspect is happening:

• CLI that works: openclaw browser --browser-profile user snapshot --interactive
• chat tool that fails: plain/default snapshot, which can take the weaker AI/ARIA path and return only rootwebarea

A really good smoke test is:

openclaw browser --browser-profile user snapshot
openclaw browser --browser-profile user snapshot --interactive

If the first one gives rootwebarea but --interactive gives the full page, that’s the smoking gun.

Best fix

Set browser snapshot defaults so omitted-mode snapshots use the better interactive-style path:

{
  browser: {
    defaultProfile: "user",
    snapshotDefaults: {

      mode: "efficient"
    }
  }
}

Then restart the gateway:

openclaw gateway restart

mode: "efficient" makes default snapshots behave like the compact role snapshot preset, which is much better for agent driving than the plain snapshot path.

Also update your skill

Make it explicit, something like:

For Shopee/voucher pages, always use browser profile user. Start with an interactive/efficient snapshot. If the snapshot only shows rootwebarea, retry with role snapshot mode before doing anything else.

So yes, yesterday it probably “worked” because the model happened to choose the better snapshot call. Today it likely chose the plain snapshot path.

If you try the two CLI commands above, paste the outputs. That will confirm this almost immediately.

Yep, with that config, I’m pretty convinced this is snapshot mode drift, not profile drift.

You already have the important bits right:

• browser.defaultProfile = "user"
• agents.defaults.sandbox.browser.allowHostControl = true

So the next check is just this:

openclaw browser --browser-profile user snapshot
openclaw browser --browser-profile user snapshot --interactive

If plain snapshot gives rootwebarea but --interactive gives the full DOM, then the in-chat agent is just taking the weaker default snapshot path.

In that case, fix it by setting:

{
  browser: {
    defaultProfile: "user",
    snapshotDefaults: {
      mode: "efficient"
    }
  }
}

Then restart:

openclaw gateway restart

And in your skill, explicitly tell it to start with an interactive/efficient snapshot on Shopee pages.

If you paste the outputs of those two snapshot commands, we can confirm it fast.

[plain hare]

I see full DOM from all commands
openclaw browser --browser-profile user snapshot
openclaw browser --browser-profile user snapshot --interactive

[wise matrix]

Ah, that’s useful. If all CLI snapshot variants show full DOM, then the browser runtime is fine.

So now I’d narrow it to chat-agent state/tool invocation, not config.

Most likely causes now:

• the in-chat agent is snapshotting the wrong tab
• it is not reusing the right targetId
• the long-lived chat/session has stale browser state
• or the model is simply choosing a bad browser call in that thread

My recommendation, in order:

1. Start a fresh chat/session/thread and retry there.
   Since your CLI path is healthy, this is the fastest sanity check.

2. Make the skill more explicit, for example:

• first list/focus the correct tab
  • take snapshot on that tab
  • reuse the returned targetId
  • do not rely on implicit active-tab selection

3. During a bad in-chat run, tail logs:

   openclaw logs --follow
   

   and compare that run against the working CLI behavior.

I’d update the skill to say something like:

For Shopee/voucher pages, first identify the correct browser tab, focus it, then snapshot that exact tab and reuse its targetId for all follow-up actions. Do not rely on the default active tab.

If a fresh session still reproduces it, I’d call that bug-shaped and file an issue with:

• openclaw --version

• your working CLI command
• the failing in-chat behavior
• relevant openclaw logs --follow lines

Issue tracker: https://github.com/openclaw/openclaw/issues

If you want, I can help you write the exact skill text next.

Perfect, that rules out config and snapshot mode.

So the problem is almost certainly the in-chat agent path itself, usually one of:

• wrong tab selected
• stale chat/session browser state
• not reusing the right targetId
• skill prompt too implicit, so the model makes a sloppy browser call

At this point, I would stop changing browser config and tighten the skill.

You can drop in something like this:

For Shopee and voucher pages:

- Always use browser profile "user".
- Before any snapshot or action, list tabs and identify the correct Shopee tab by URL/title.
- Focus that tab explicitly.
- Take the snapshot on that exact tab and reuse its targetId for every follow-up browser call.
- Prefer an interactive snapshot for element picking.
- If a snapshot returns only "rootwebarea", do not continue. Re-list tabs, re-focus the correct tab, and snapshot again.
- Do not assume the current active tab is correct.
- Do not open a new tab unless the user asked for one.

What I’d try next:

1. fresh thread/session
2. use the stricter skill text above
3. if it still happens, openclaw logs --follow during the bad run