Problem
The browse binary starts a fresh Chromium server on every process invocation. When used from Claude Code (where each Bash tool call runs in a separate shell process), this means:
- Element refs from
snapshot are lost between commands
- Auth cookies don't persist after login
- Page navigation state resets to
about:blank
This makes /qa browser testing very difficult. The workaround is chaining all browse commands in a single Bash call, which works but is fragile and hard to maintain.
Reproduction
B=~/.claude/skills/gstack/browse/dist/browse
# Call 1: navigate and get refs
$B goto http://localhost:3000/login
$B snapshot -i
# Output: @e1 [textbox] "Email" ...
# Call 2 (separate shell process): refs are gone
$B fill @e1 "user@example.com"
# Output: [browse] Starting server...
# Ref @e1 not found. Run 'snapshot' to get fresh refs.
Same commands chained in a single shell process work fine:
$B goto http://localhost:3000/login && $B snapshot -i && $B fill @e1 "user@example.com"
# Works: Navigated, snapshot taken, field filled
Expected behavior
The browse binary should discover and connect to an already-running server instead of launching a new one. Common pattern:
- On first invocation: start the server, write PID + port to a discovery file (e.g.,
/tmp/gstack-browse-$USER.json)
- On subsequent invocations: check the discovery file, verify the server is alive (
kill -0), connect to it
$B stop cleans up the discovery file
This is how vite, webpack-dev-server, and Playwright's persistent context handle it.
Environment
- gstack v0.16.1.0
- macOS Darwin 25.2.0 (arm64)
- Claude Code CLI (each Bash tool call is a separate shell process)
Impact
The /qa skill relies heavily on multi-step browser interactions (login, navigate, interact, screenshot). Without persistent server state, every workflow must be crammed into a single Bash call, which is error-prone and limits the depth of testing.
Problem
The
browsebinary starts a fresh Chromium server on every process invocation. When used from Claude Code (where each Bash tool call runs in a separate shell process), this means:snapshotare lost between commandsabout:blankThis makes
/qabrowser testing very difficult. The workaround is chaining all browse commands in a single Bash call, which works but is fragile and hard to maintain.Reproduction
Same commands chained in a single shell process work fine:
Expected behavior
The browse binary should discover and connect to an already-running server instead of launching a new one. Common pattern:
/tmp/gstack-browse-$USER.json)kill -0), connect to it$B stopcleans up the discovery fileThis is how vite, webpack-dev-server, and Playwright's persistent context handle it.
Environment
Impact
The
/qaskill relies heavily on multi-step browser interactions (login, navigate, interact, screenshot). Without persistent server state, every workflow must be crammed into a single Bash call, which is error-prone and limits the depth of testing.