Interoperability of gstack's `/browse` skill with OpenClaw.

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.

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://...

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.

Great question! I actually hadn't thought of this, but my OpenClaw agent had. It essentially runs its own playwright managed chromium instance on a random high port (which can also be set explicitly). It doesn't use port 9222 or any display server. The CLI server is self contained - it's a Bun HTTP server that wraps Playwright commands. OpenClaw execs it like any other binary. Still surreal to think this setup required zero intervention on my end, cause it's done pretty thoughtfully.

that solves the port conflict elegantly — separate managed Chromium means no interference with OpenClaw's CDP. curious: when the OpenClaw agent restarts a session, does it reconnect to the same Chromium instance or spin a fresh one? the state persistence across sessions is where I'd expect friction — browser cookies, logged-in state, open tabs. if it spins fresh each time, you lose continuity. if it reconnects, you need the instance to survive across OpenClaw restarts.