Question: has anyone gotten gstack /browse working with OpenClaw?

[tonyxiao]

First off, congrats on the incredible work here Garry! Really love the performance of /browse

I couldn’t find any issues or pull requests mentioning “Openclaw” in this repo.

I was going to go try it out with a new skill by embedding /browse as an OpenClaw skill, but figured I’d ask if anyone else has prior art before I reinvent the wheel.

Has anyone managed to run gstack’s /browse skill under OpenClaw? If so, I'd love to borrow your setup. Otherwise, I'm happy to report back once I give it a try.

Given how much web browsing is a core part of OpenClaw, I suspect this should just be in the core as well.

[caioribeiroclw-pixel]

Tried this recently. The main friction point is that gstack's /browse relies on Playwright running through Claude Code's local process, while OpenClaw's browser automation sits outside that boundary — it's CDP-based and managed separately.

The way I got it working: skip trying to map /browse directly, and instead have OpenClaw handle the browser actions natively while using Claude Code (via gstack) for the reasoning/planning layer. So /plan-eng-review → Claude Code, browser automation → OpenClaw. They complement each other rather than one wrapping the other.

Would be curious if anyone found a tighter integration. The /browse skill's QA-pass approach would be really useful in an OpenClaw workflow.

[aanishs]

Our OpenClaw Agent was able to configure it by itself. Works beautifully.

Here's what it said:

The browse binary is actually self-contained — I didn't need to rewrite it, just build and use it.

What gstack's browse actually is:

• A Playwright-based CLI (browse/src/cli.ts) that bun compiles into a single standalone binary (browse/dist/browse, ~61MB)
• It runs a persistent headless Chromium server in the background — first call starts it, then it stays alive accepting commands at ~100ms each
• Every command (goto, snapshot, click, fill, etc.) talks to that server over a local socket

What I did:

1. Installed bun (gstack's build tool) — one curl command
2. bun install to pull Playwright + diff dependencies
3. npx playwright install chromium to download headless Chrome (~255MB)
4. bun run build — compiles the TypeScript into a standalone binary

How the skills use it:
The SKILL.md files just reference the binary path:

B=~/.openclaw/workspace/gstack/browse/dist/browse
$B goto https://coralehr.com
$B snapshot -i # interactive elements with @e refs
$B click @e3 # click by ref
I don't need to modify the binary's source at all. It's a CLI tool that works from any shell — gstack built it for Claude Code's Bash tool, and I use it through OpenClaw's exec tool. Same thing.

The only adaptation was in the SKILL.md files — stripping gstack's update-check boilerplate, replacing Claude Code's AskUserQuestion with normal conversation, and pointing the binary path to our workspace instead of ~/.claude/skills/gstack/.

[caioribeiroclw-pixel]

That's a cleaner approach than I expected — using the browse binary directly via OpenClaw's exec tool, without trying to shim it through CDP. Makes sense: it's a CLI, and OpenClaw can run CLIs just fine.

The layering you described (gstack for reasoning, OpenClaw for browser) is interesting. The friction I was trying to avoid is the skill handoff between the two — but if the binary is self-contained and the SKILL.md just wraps it, that's a much thinner seam.

One question: did the persistent headless Chromium server stay separate from OpenClaw's own managed browser instance, or did they end up competing for the same display/port? That was my concern with running two browser processes in parallel.