snapshot browser return empty DOM

[winter depot]

I try using openclaw to snapshot my browser but it keeps telling me 'Nothing return due to empty DOM'

But when I try on my cli it return all elements I need like this. '
bas.kertiopa@H1W0Q4D0MH .openclaw % openclaw browser --browser-profile user snapshot --target-id 5 2>/dev/null | grep -E "voucher|Voucher|Budget|button" | head -10
- link "Logo - Voucher Portal" [ref=1_3]
- statictext " - Voucher Portal"
- button "All Prefix List" [ref=1_7]
- button "Instruction" [ref=1_9]
- link "Voucher" [ref=1_16]
- statictext "Voucher"
- statictext "Budget"
- statictext "Voucher"
- statictext "Voucher"
- button "Settings" [ref=1_24]' why how to solve?

[celest narwhal]

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

[tropic grotto]

Your CLI output is the clue, OpenClaw is almost certainly not snapshotting the same browser context when the agent runs it.

Most likely causes:

1. Wrong profile
   The browser tool defaults to the isolated openclaw browser.
   Your working CLI command explicitly uses --browser-profile user.

2. Wrong tab
   For the user profile, snapshot reads the selected live tab unless you pass a targetId.
   Your CLI command explicitly uses --target-id 5.

So the agent/tool call needs to match your CLI call, basically:

openclaw browser --browser-profile user snapshot --target-id 5

If you're driving it through the browser tool, make sure it uses:

• profile="user"
• targetId="5"

Also worth trying:

openclaw browser --browser-profile user tabs
openclaw browser --browser-profile user focus 5
openclaw browser --browser-profile user snapshot --target-id 5 --interactive

If the page content is inside an iframe, use a frame-scoped role snapshot:

openclaw browser --browser-profile user snapshot --target-id 5 --interactive --frame "iframe"

Docs:

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

Also, what does openclaw --version say? If you paste that plus the output of openclaw browser --browser-profile user tabs, I can narrow it down fast.

[winter depot]

bas.kertiopa@H1W0Q4D0MH .openclaw % openclaw --version
OpenClaw 2026.4.4 (559e42b)

[tropic grotto]

Yep, that version is old enough that I’d update first.

2026.4.4 is behind a bunch of browser fixes, including user / existing-session routing and CDP attach stuff. I wouldn’t spend too long debugging browser weirdness on that build.

What your result tells us:

• your CLI attach is working
• the DOM is not actually empty
• the failing path is probably either:
  1. the agent/browser tool is hitting the wrong profile or tab, or
  2. you’re on one of the older browser bugs in 2026.4.4

I’d do this next:

openclaw update

openclaw browser --browser-profile user status
openclaw browser --browser-profile user tabs
openclaw browser --browser-profile user focus 5
openclaw browser --browser-profile user snapshot --target-id 5 --interactive

A couple important gotchas:

• the browser tool defaults to the isolated openclaw profile unless you force user
• with user, snapshot reads the selected live tab unless you pass targetId
• if the page is inside an iframe, try:

openclaw browser --browser-profile user snapshot --target-id 5 --interactive --frame "iframe"

Also, if your Gateway and Chrome are not on the same machine (or WSL vs Windows split), user / existing-session is the wrong mode for agent/browser-tool calls. In that case use remote CDP or a browser node instead.

Docs:

• https://docs.openclaw.ai/tools/browser
• https://docs.openclaw.ai/cli/browser
• https://docs.openclaw.ai/gateway/troubleshooting

If it still breaks after updating, paste:

• openclaw browser --browser-profile user status
• openclaw browser --browser-profile user tabs

and I can narrow it down fast.

Ah, this helps a lot.

This does not look like a real “empty DOM” problem anymore. It looks like a messy/stale install.

Your earlier command worked because 2>/dev/null hid the important part: you have

• duplicate bundled plugins under ~/.openclaw/extensions/*
• a broken bundled Slack load from .../openclaw-source/dist-runtime/...

That combo can make browser behavior flaky.

I’d fix the install first, in this order:

openclaw update
openclaw doctor --fix

openclaw gateway restart
openclaw browser --browser-profile user status --json 2>/dev/null
openclaw browser --browser-profile user tabs --json 2>/dev/null

Why I’m leaning that way:

• plugins.entries.browser being duplicated is suspicious for browser-tool weirdness
• failed to load bundled channel slack ... TypeError ... means part of the runtime is out of sync
• your actual snapshot output proves the page DOM is there

If the duplicate warnings are still there after update + doctor, paste the plugins section of your ~/.openclaw/openclaw.json with secrets redacted.
I’d specifically want to see why you have local entries for:

• browser
• brave

• openai
• seatalk

If those are custom plugins, they should not reuse the same ids as bundled ones.

Docs:

• https://docs.openclaw.ai/install/updating
• https://docs.openclaw.ai/gateway/troubleshooting

If you want, paste the output of the 2 JSON commands after update and I’ll tell you exactly what’s off.

Yep, that confirms it, what you pasted there is basically plugin/config noise, not the actual tab list.

So there are 2 separate problems:

1. Browser snapshot itself works
   Your snapshot --target-id 5 2>/dev/null proves that.

2. Your install is auto-discovering old local plugins
   browser, brave, openai, seatalk are sitting in ~/.openclaw/extensions/..., and plugins.allow is empty, so OpenClaw keeps warning about them.

I’d clean that up first:

openclaw update
openclaw doctor --fix
openclaw gateway restart

Then make plugins.allow explicit, at least including the plugins you actually trust/use.
Important: if you set plugins.allow, it must include browser or the browser surface can disappear.

After that, rerun this so we get the real stdout, not warning spam:

openclaw browser --browser-profile user tabs --json 2>/dev/null
openclaw browser --browser-profile user status --json 2>/dev/null

One more thing: those duplicate ids strongly suggest you have old local extension copies shadowing bundled plugins. If you are not intentionally developing custom versions of browser, brave, openai, or seatalk, I would remove those old plugin entries/config next.

So short version: this is looking more like stale plugin/install state than an actual DOM bug.

If you paste:

• tabs --json 2>/dev/null
• status --json 2>/dev/null

after update/doctor, I can tell you the next exact fix.

You’re still on 2026.4.4, so the update step hasn’t happened yet.

Also, this paste is still just warning output, not the clean status/tabs JSON I need to debug the browser side.

So I’d stop here and do these exact steps first:

openclaw update
openclaw doctor --fix
openclaw gateway restart
openclaw browser --browser-profile user status --json 2>/dev/null
openclaw browser --browser-profile user tabs --json 2>/dev/null

Then paste the last 2 outputs only.

Right now the main issue is still:

• old build (2026.4.4)
• stale local plugins under ~/.openclaw/extensions/*
• plugins.allow unset/empty, so local plugins may auto-load

If you can’t update right now, then paste just the plugins section from ~/.openclaw/openclaw.json with secrets redacted, and I’ll point at the exact bad entries.

Nice, that narrows it down a lot.

Your browser side is not empty:

• the user profile sees the page
• tab 5 exists
• your manual snapshot --target-id 5 returns the elements

So the remaining problem is almost certainly:

1. the agent/browser tool is using the wrong profile (openclaw instead of user), or
2. it is snapshotting the wrong tab because targetId is not being passed

I’d treat the fix as:

openclaw browser --browser-profile user focus 5
openclaw browser --browser-profile user snapshot --target-id 5 --interactive 2>/dev/null

And if you’re asking the agent to do it, make sure it uses:

• profile="user"
• targetId="5"

You also have the same page open on tab 3 and tab 5, so if one behaves oddly, try the other explicitly too.

So at this point I’d say:

• DOM is fine
• browser attach is fine
• problem is target selection / tool invocation defaults

The plugin warnings are still worth cleaning up later, but they don’t look like the core “empty DOM” issue anymore.

If you want, paste the exact prompt/tool call you’re using when OpenClaw says “empty DOM”, and I can tell you exactly what parameter is missing.

[winter depot]

How to fix this 'problem is target selection / tool invocation defaults'

[tropic grotto]

Easiest fix: stop relying on defaults.

Best fix

Use the exact tab + profile every time:

openclaw browser --browser-profile user focus 5
openclaw browser --browser-profile user snapshot --target-id 5 2>/dev/null

If you’re asking the agent in chat

Be explicit:

Use the browser tool with profile=user.
List tabs, focus targetId=5, then snapshot targetId=5.

If you just say “snapshot my browser”, it may:

• use the default openclaw profile instead of user
• inspect the wrong tab

To reduce mistakes

You currently have the same page open in tab 3 and tab 5.
Close one of them, or always target one id explicitly.

Optional config fix

If you want user to be the default browser profile, set:

{
  browser: {
    defaultProfile: "user",
  },
}

then restart:

openclaw gateway restart

But important: this only fixes the profile default.
You still need targetId=5 or focus 5 to fix the tab default.

My recommendation:

• keep using profile=user
• always pass targetId
• close duplicate tabs if possible

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

[winter depot]

Can you help summary what should I do to fix?

[tropic grotto]

Yep, short version:

What to do

1. Update + clean up

   openclaw update
   openclaw doctor --fix
   openclaw gateway restart
   

2. Use the user browser profile
   Do not rely on the default browser profile.

3. Always target the exact tab
   Your working tab is 5:

   openclaw browser --browser-profile user focus 5
   openclaw browser --browser-profile user snapshot --target-id 5 2>/dev/null

4. Close duplicate tabs if possible
   You had the same page open on tab 3 and tab 5, which makes defaults confusing.

5. If using the agent/chat
   Tell it explicitly:

   • use profile=user
   • use targetId=5

Optional

If you want user as the default browser profile:

{
  browser: {
    defaultProfile: "user",
  },
}

Then restart the gateway.

Why this fixes it

Your DOM is not empty.
The problem is mostly:

• old/stale install/plugin noise
• wrong browser default
• wrong tab default

If you want, I can turn this into a tiny “do these 3 commands” version too.

[winter depot]

I just wondering my openclaw using the correct code to snapshot? openclaw tell me after I asking him to show me the code he use to snapshot website, he said 'I’m calling the built-in browser tool like this (for your voucher tab targetId 6):

{
  "action": "snapshot",
  "target": "host",
  "profile": "user",
  "targetId": "6"
}

i.e. browser action=snapshot targetId=6 profile=user target=host with no extra flags.'

[tropic grotto]

The shape of that call is correct, yes.

{
  "action": "snapshot",
  "target": "host",
  "profile": "user",
  "targetId": "6"
}

But the likely problem is not the code shape, it’s the tab id.

Earlier your voucher page was on tab 3 and tab 5.
If OpenClaw is now using targetId 6, it may be snapshotting a different tab, which would explain the “empty DOM”.

So the answer is:

• action: "snapshot" ✅
• target: "host" ✅, if OpenClaw and Chrome are on the same machine
• profile: "user" ✅
• targetId: "6" ❓ probably the problem

Best fix

Have it do this flow every time:

1. list tabs
2. find the voucher tab
3. use that exact targetId
4. snapshot that tab

For example, if the voucher page is really tab 5:

{
  "action": "snapshot",
  "target": "host",
  "profile": "user",
  "targetId": "5"
}

Even better

Ask it to use an interactive snapshot:

{
  "action": "snapshot",
  "target": "host",

  "profile": "user",
  "targetId": "5",
  "interactive": true
}

Important note

If your Gateway is not on the same machine as Chrome, then target: "host" may be wrong too.
But if your local CLI works with --browser-profile user, then the bigger issue is still probably the wrong targetId.

So, short answer: the code format is fine, but the targetId looks wrong.

[winter depot]

No I actually have targetID = 6 for real

[tropic grotto]

Got it. If targetId=6 is real, then the call is basically correct.

So if this still returns “empty DOM”, I’d stop blaming targetId and change the snapshot mode instead of relying on defaults.

Try this first

Make the snapshot format explicit:

{
  "action": "snapshot",
  "target": "host",
  "profile": "user",
  "targetId": "6",
  "snapshotFormat": "ai"
}

Also good to try

Force an interactive role snapshot:

{
  "action": "snapshot",
  "target": "host",
  "profile": "user",
  "targetId": "6",
  "interactive": true
}

If the page is inside an iframe

Then plain snapshot can miss the real content. Try:

{
  "action": "snapshot",
  "target": "host",
  "profile": "user",
  "targetId": "6",
  "interactive": true,
  "frame": "iframe"
}

One more thing

Focus the tab first, then snapshot it:

1. focus targetId=6
2. snapshot targetId=6

So the updated diagnosis is:

• target=host ✅
• profile=user ✅
• targetId=6 ✅
• default snapshot mode may be the actual problem ❗

If you want, I can give you the exact browser tool JSON I’d use as the “safest” version for this page.

[winter depot]

It's not work

[tropic grotto]

Ugh, that’s frustrating.

At this point I need the exact raw output, otherwise we’re guessing.

Please paste these 3 commands exactly:

openclaw --version
openclaw browser --browser-profile user tabs 2>/dev/null
openclaw browser --browser-profile user snapshot --target-id 6 2>/dev/null | head -50

And if that third one is empty, also paste:

openclaw browser --browser-profile user snapshot --target-id 6 --interactive 2>/dev/null | head -50