Cloud Google Chrome and Remote Browser Control in OpenClaw Box

One of the most important product upgrades we have shipped recently is that OpenClaw Box tenants now have a much more usable cloud browser story.

That means the browser is no longer something you have to imagine as "probably available somewhere in the runtime." It is now exposed as a practical surface you can actually open and use.

Every tenant now ships with a browser stack, not just a browser binary

The key change is not only that Chrome exists in the environment.

The tenant template now pulls together the whole browsing path:

• a dedicated browserless Chrome sidecar
• a browser UI exposed on /browser/
• a preinstalled chrome-cdp binary inside the tenant workspace
• a bundled chrome skill
• workspace instructions that tell the agent to use chrome-cdp first for browsing tasks

That bundle matters because real browser capability is more than one executable dropped into a container.

The agent needs the process, the CDP endpoint, the tool binary, the skill prompt, and the default behavior guidance. Once those pieces are shipped together, browsing becomes a default operating mode instead of a half-manual setup.

/status is now the control handoff

We also made the browser easier to find.

The /status command now shows two clearly labeled URLs:

• Control Panel
• Browser

That was a practical usability fix.

Previously, browser access was easier to miss or easier to confuse with the main tenant URL. Now users can open /status, see the Browser link directly, and know exactly where remote browser control lives.

Remote browser control works through the browser URL

Once you follow the Browser link from /status, you land on the tenant browser UI. From there, the runtime can use its cloud browser remotely instead of depending on a desktop-only attachment model.

This is especially important in path-mode routing, where browser links also need the correct gatewayUrl query parameter. Without that extra routing context, the browser UI may connect to the wrong websocket path and fail with disconnects.

We tightened that up so the browser link from /status carries the right routing information when needed.

The product outcome is simple:

follow the Browser URL from /status, and you can control OpenClaw's cloud browser remotely.

That turns the tenant into something closer to a hosted operator environment instead of a chat-only endpoint.

Why the preinstalled chrome-cdp skill matters

We also wanted the browsing behavior to be obvious to the runtime itself.

The seeded workspace now includes guidance that tells the agent:

• use chrome-cdp for browsing and web automation
• do not rely on the built-in browser tool in this deployment
• do not ask the user to attach tabs or install extensions
• attempt cloud browsing first, then fall back only when access is blocked by site login or policy

This is important because the product should not require the user to understand internal tooling choices.

The agent should already know the intended path. That is what the skill and seeded workspace policy accomplish.

Why this is a meaningful step for OpenClaw Box

OpenClaw Box is gradually becoming more than "managed hosting for an assistant runtime."

It is becoming a place where the runtime can actually operate:

• via Telegram
• via its tenant control panel
• and now via a clearer, built-in cloud browser surface

That makes the product much more useful for tasks that need both chat and web execution.

The browser is no longer an abstract capability. It is a surfaced part of the tenant experience.