@clawnify/browser-tabs

Per-agent browser tab isolation for OpenClaw agents that share one Chrome.

Why

Clawnify runs multiple agents (main + specialists) in one gateway driving a single shared Chrome over one CDP endpoint. They therefore share one flat tab namespace, and when several run at once they collide — the live gateway logs show tab not found, action targetId must match request targetId, and stale refs, because one agent's snapshot/act lands on a tab another agent changed.

This plugin scopes the browser per agent so an agent may only act on tabs it opened, while all agents keep the same shared profile (shared logins).

What it does

Entirely at the tool-call boundary (no browser fork required):

• after_tool_call (observe) — reads every browser result to track the current targetId/tabId/label handles, assign ownership of tabs an agent opens (or first acts on, keyed by ctx.agentId), and prune closed tabs.
• before_tool_call (enforce) — blocks a target that resolves to another agent's tab, and injects the agent's own last tab when the model omits a target on snapshot/act/screenshot/console (so the shared service can't default onto a foreign tab).

Scope (honest)

This delivers action isolation — agents can't act on each other's tabs and default onto their own, which removes the collision errors above. It does not hide foreign tabs from the action=tabs list: a plugin cannot rewrite the live tool result the model sees (after_tool_call is observe-only; tool_result_persist only transforms the persisted copy). Complete list-scoping requires a browser-service change, proposed upstream to openclaw/openclaw. Since a VPS is a single organization, the residual visibility is intra-tenant.

Enforcement is fail-open on unobserved handles (never breaks a legitimate first use) and fail-safe on known-foreign handles (blocked). The airtight, list-scoping version is the upstream change.

Config

{ "enabled": true } // default; set false to disable without uninstalling

Install

Pure string/Map work — no child_process/eval — so it loads as a normal external plugin (unlike the bundled browser plugin). Shipped to the fleet via the standard Clawnify internal-plugin pattern (R2 tarball + cloud-init register in openclaw.json plugins.entries/load.paths/allow), the same path as @clawnify/secret-inputs.

MIT.