mirror of
https://github.com/garrytan/gstack.git
synced 2026-08-29 09:20:39 +02:00
* fix(browse): revokeToken deletes ALL tokens for a clientId, not the first Map hit
revokeToken deleted the first Map entry matching the clientId and returned
true. After a normal pairing, two entries share one clientId: the spent setup
key (kept by exchangeSetupKey for idempotent re-exchange) and the session
token, in that insertion order. Revoke ate the setup key, reported success,
and the live session survived: DELETE /token/<id> returned a false 200 while
/agents kept listing the agent. Worse, an unspent setup key created after the
session survived revoke, so a "revoked" agent could POST /connect and mint a
fresh session within the key's 5-minute validity window.
revokeToken now deletes every matching entry and returns the delete count
(truthy-compatible with the old boolean). The DELETE /token handler logs
"Revoked N token(s)" and returns tokens_deleted so the multi-token class
stays visible; revokeSkillToken wraps Boolean() to keep its documented
contract. Regression tests pin shapes a (spent-key shadowing), b (re-grant
hole), c (multiple pending keys), and bystander isolation.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* feat(browse): tunnel revoke/agents CLI with post-revoke verification
`$B tunnel revoke <name>` was documented in the instruction block,
pair-agent/SKILL.md, and REMOTE_BROWSER_ACCESS.md but implemented nowhere:
the CLI forwarded it to the daemon as Unknown command 'tunnel', and nothing
in the repo called DELETE /token/:clientId or GET /agents.
New pre-server short-circuit (#2254 pattern: tokens are memory-only, never
boot a daemon to revoke against it). `tunnel revoke <name>` DELETEs the
token, prints the deleted count ("(count unknown)" for old daemons that
answer {revoked} without tokens_deleted), then RE-READS GET /agents to prove
the agent is gone. The still-listed branch is the version-skew net: a new
CLI against a still-running old daemon with the first-match revoke bug exits
1 and says to re-run (each old-daemon call deletes the next match) or stop.
An alive pid with an unreachable port reports "Could not reach daemon"
(exit 1), never a false "no daemon". `tunnel agents` lists sessions plus
pending (unexchanged) setup keys, which GET /agents now exposes via
listTokens({includeSetup}) — without them the revocation view was blind to
a paired-but-never-connected agent. Setup-key tokens never leave the server.
DELETE /token/ now decodeURIComponents the clientId (400 on malformed
encoding) so CLI-encoded names round-trip.
Tests: subprocess CLI coverage (usage paths, no-daemon exit 0 without
spawning, live pair/connect/revoke loop, pending-key listing), stub-daemon
pins for the skew and unreachable branches, and e2e pins for revoke-all
semantics, percent-encoded ids, and the second-DELETE-is-404 regression.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(browse): CLI always sends explicit pair scopes via shared DEFAULT_PAIR_SCOPES
The effective pairing default lived in two places: the CLI omitted scopes
unless --restrict was passed, and the server filled in its own literal.
handlePairAgent now always sends an explicit scopes list and both sides
reference one exported constant, DEFAULT_PAIR_SCOPES, so the default cannot
silently drift again (pinned by a server-auth source tripwire).
Three input traps closed in the same surface:
- Bare --restrict (or --restrict swallowing the next flag) parsed as "no
restriction" and silently granted FULL access, the opposite of the user's
intent. validatePairAgentFlags rejects it pre-server, before any consent
gate, so an arg error never boots a daemon.
- A scopes list could smuggle the control scope past the explicit flag:
--restrict "read,control" minted a control-scoped session with no
--control. /pair now 400s on control in a scopes list without the control
flag, and the CLI points the user at --control.
- Option typos validated only at exchange time: createSetupKey stored any
scope string and any rateLimit, so /pair returned 200 with a poisoned
setup key whose failure surfaced to the REMOTE agent at /connect as a
misleading "Invalid request body". Shared validation now runs in both
creators and throws typed InvalidScopeError; /pair and /token 400 with the
message, naming the bad scope or negative rateLimit. Also
`opts.rateLimit || 10` became `?? 10` so the documented "0 = unlimited"
survives the /pair path.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(browse): 403 hint stops recommending --admin; invariant names both scope defaults
The scope-denied hint told restricted agents to "re-pair with --admin for
eval/cookies/storage" — but --admin is a legacy alias for --control, so
following it over-granted browser-wide destructive commands on top of the
admin scope the default already carries. The hint now matches the CLI's
sibling wording: re-pair without --restrict for page access, --control for
browser control.
Registry invariant #2 claimed "admin scope denied by default" three releases
after b73f3644 deliberately made /pair grant admin. It now names BOTH
defaults precisely (registry API functions default read+write; the /pair
ceremony grants DEFAULT_PAIR_SCOPES) so the header cannot lie one layer down.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs(pair-agent): document the full-access default, --restrict, and real revocation
The pairing docs still described the pre-b73f3644 model: read+write default,
--admin as the opt-in for JS/cookies/storage. Reality for three releases:
/pair grants read+write+admin+meta (the pairing ceremony is the trust
boundary) and --admin is a legacy alias for --control. A user following the
skill believed they granted a sandboxed session and actually granted JS
execution on their logged-in browser.
pair-agent/SKILL.md.tmpl (SKILL.md regenerated in this commit) now states
the real default, the tunnel-allowlist nuance (eval works remotely; the
js/cookies/storage commands are local-only), --restrict for sandboxed
sessions with an untrusted-content advisory (scope caps prompt-injection
blast radius), and --control for browser-wide ops. "Revoking access"
documents the now-real tunnel revoke (deletes session + pending setup keys,
verifies against the agent list) and tunnel agents, and replaces the
never-implemented `tunnel rotate` with `$B stop` — tokens are memory-only,
so a daemon restart already rotates everything.
REMOTE_BROWSER_ACCESS.md: /connect example shows the real default scopes,
the scope table gains the control row, the 403 hint row matches the new
server wording, and the false claim that /sidebar-chat is on the tunnel
allowlist is gone (TUNNEL_PATHS is /connect + /command; /sidebar-chat no
longer exists in server.ts at all). ARCHITECTURE.md drops the same phantom
endpoint from the allowlist prose and endpoint table.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* v1.68.2.0: revoke-all, real tunnel revoke, truthful pairing docs
Version slot allocated against the live remote via bin/gstack-next-version
(clean patch bump from 1.68.1.0, no collision). CHANGELOG entry covers the
revoke-all fix, the new tunnel revoke/agents CLI, the explicit-scopes wire
contract, and the pairing-docs truth pass.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(browse): adversarial-review hardening — 6 findings fixed, regression-pinned
Pre-push adversarial review (4 lenses, refute-style verification: 13 raw
findings, 7 refuted, 6 confirmed) caught these; each fix carries a pin:
1. --restrict=read (equals form) sailed past validatePairAgentFlags —
hasFlag/parseFlag are exact-token matches — so the user asked for a
read-only sandbox and silently got FULL access: the exact failure mode
this branch claims to close. The equals form is now a hard error before
any server work.
2. handleTunnel trimmed the agent name but clientIds are stored verbatim,
so a space-padded agent was unrevocable by the documented kill switch
(trimmed DELETE 404'd while the grant stayed live). Names now pass
through verbatim; the live-daemon test revokes ' padded'.
3. The sole pin for "CLI always sends explicit scopes" passed vacuously on
a simulated revert: toContain('DEFAULT_PAIR_SCOPES') was satisfied by a
comment. The tripwire now matches the code shape with a regex and bans
the conditional spread formatting-insensitively.
4. The rewritten 403 scope hint was unpinned — new e2e asserts it names
--restrict and --control and never --admin.
5. tunnelRevoke's verify-failure and HTTP-error branches and tunnelAgents'
unreadable-list branch had no coverage — three stub-daemon pins added
(an unreadable list must never render as "No paired agents").
6. CHANGELOG claimed "40+ new test cases"; the honest count is 35.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
359 lines
12 KiB
Cheetah
359 lines
12 KiB
Cheetah
---
|
|
name: pair-agent
|
|
preamble-tier: 2
|
|
version: 0.1.0
|
|
description: |
|
|
Pair a remote AI agent with your browser. One command generates a setup key and
|
|
prints instructions the other agent can follow to connect. Works with OpenClaw,
|
|
Hermes, Codex, Cursor, or any agent that can make HTTP requests. The remote agent
|
|
gets its own tab with full page access by default (the pairing ceremony is the
|
|
trust boundary; --restrict narrows it).
|
|
Use when asked to "pair agent", "connect agent", "share browser", "remote browser",
|
|
"let another agent use my browser", or "give browser access". (gstack)
|
|
voice-triggers:
|
|
- "pair agent"
|
|
- "connect agent"
|
|
- "share my browser"
|
|
- "remote browser access"
|
|
triggers:
|
|
- pair with agent
|
|
- connect remote agent
|
|
- share my browser
|
|
allowed-tools:
|
|
- Bash
|
|
- Read
|
|
- AskUserQuestion
|
|
|
|
---
|
|
|
|
{{PREAMBLE}}
|
|
|
|
# /pair-agent — Share Your Browser With Another AI Agent
|
|
|
|
You're sitting in Claude Code with a browser running. You also have another AI agent
|
|
open (OpenClaw, Hermes, Codex, Cursor, whatever). You want that other agent to be
|
|
able to browse the web using YOUR browser. This skill makes that happen.
|
|
|
|
## How it works
|
|
|
|
Your gstack browser runs a local HTTP server. This skill creates a one-time setup key,
|
|
prints a block of instructions, and you paste those instructions into the other agent.
|
|
The other agent exchanges the key for a session token, creates its own tab, and starts
|
|
browsing. Each agent gets its own tab. They can't mess with each other's tabs.
|
|
|
|
The setup key expires in 5 minutes and can only be used once. If it leaks, it's dead
|
|
before anyone can abuse it. The session token lasts 24 hours.
|
|
|
|
**Same machine:** If the other agent is on the same machine (like OpenClaw running
|
|
locally), you can skip the copy-paste ceremony and write the credentials directly to
|
|
the agent's config directory.
|
|
|
|
**Remote:** If the other agent is on a different machine, you need an ngrok tunnel.
|
|
The skill will tell you if one is needed and how to set it up.
|
|
|
|
{{BROWSE_SETUP}}
|
|
|
|
## Step 1: Check prerequisites
|
|
|
|
```bash
|
|
$B status 2>/dev/null
|
|
```
|
|
|
|
If the browse server is not running, start it:
|
|
|
|
```bash
|
|
$B goto about:blank
|
|
```
|
|
|
|
This ensures the server is up and healthy before pairing.
|
|
|
|
## Step 2: Ask what they want
|
|
|
|
Use AskUserQuestion:
|
|
|
|
> Which agent do you want to pair with your browser? This determines the
|
|
> instructions format and where credentials get written.
|
|
|
|
Options:
|
|
- A) OpenClaw (local or remote)
|
|
- B) Codex / OpenAI Agents (local)
|
|
- C) Cursor (local)
|
|
- D) Another Claude Code session (local or remote)
|
|
- E) Something else (generic HTTP instructions — use this for Hermes)
|
|
|
|
Based on the answer, set `TARGET_HOST`:
|
|
- A → `openclaw`
|
|
- B → `codex`
|
|
- C → `cursor`
|
|
- D → `claude`
|
|
- E → generic (no host-specific config)
|
|
|
|
## Step 3: Local or remote?
|
|
|
|
Use AskUserQuestion:
|
|
|
|
> Is the other agent running on this same machine, or on a different machine/server?
|
|
>
|
|
> **Same machine** skips the copy-paste ceremony. Credentials are written directly to
|
|
> the agent's config directory. No tunnel needed.
|
|
>
|
|
> **Different machine** generates a setup key and instruction block. If ngrok is
|
|
> installed, the tunnel starts automatically. If not, I'll walk you through setup.
|
|
>
|
|
> RECOMMENDATION: Choose A if the agent is local. It's instant, no copy-paste needed.
|
|
|
|
Options:
|
|
- A) Same machine (write credentials directly)
|
|
- B) Different machine (generate instruction block for copy-paste)
|
|
|
|
## Step 4: Execute pairing
|
|
|
|
**Live-daemon consent (one-way door).** Pairing can relaunch the browser
|
|
daemon; a relaunch KILLS the running headless daemon — open tabs, cookies,
|
|
and logged-in sessions die with it. The CLI honors the iron rule (only an
|
|
explicit `--force-restart` may kill a live daemon), so check first:
|
|
|
|
```bash
|
|
$B status 2>/dev/null | head -5
|
|
```
|
|
|
|
If a daemon is running, ask via AskUserQuestion (one-way door — lost
|
|
tabs/cookies/logins cannot be recovered):
|
|
|
|
> "A headless browser daemon is live (tabs and logins may be active). Pairing
|
|
> headed requires relaunching it — everything in the current daemon is lost.
|
|
>
|
|
> RECOMMENDATION: Choose B unless the remote agent specifically needs a
|
|
> visible browser window; pairing works against the existing daemon."
|
|
|
|
Options:
|
|
- A) Relaunch (pass `--force-restart`; current tabs/cookies/logins are lost)
|
|
- B) Keep the live daemon (recommended — pair against it as-is)
|
|
|
|
Only pass `--force-restart` to the commands below after an explicit A. Never
|
|
default to A on a vague reply — this is a destructive confirmation.
|
|
|
|
### If same machine (option A):
|
|
|
|
Run pair-agent with --local flag:
|
|
|
|
```bash
|
|
$B pair-agent --local TARGET_HOST
|
|
```
|
|
|
|
Replace `TARGET_HOST` with the value from Step 2 (openclaw, codex, cursor, etc.).
|
|
|
|
If it succeeds, tell the user:
|
|
"Done. TARGET_HOST can now use your browser. It will read credentials from the
|
|
config file that was written. Try asking it to navigate to a URL."
|
|
|
|
If it fails (host not found, write permission error), show the error and suggest
|
|
using the generic remote flow instead.
|
|
|
|
### If different machine (option B):
|
|
|
|
**Consent gate (once per machine).** The tunnel exposes this browser beyond
|
|
the machine, so it is OFF until the user opts in — the daemon refuses
|
|
`/tunnel/start` and `BROWSE_TUNNEL=1` otherwise. Check the standing consent:
|
|
|
|
```bash
|
|
~/.claude/skills/gstack/bin/gstack-config get pair_agent 2>/dev/null || echo "unset"
|
|
```
|
|
|
|
If the value is not `on`, ask via AskUserQuestion (one-way-door posture —
|
|
this opens a path from the internet to the local browser):
|
|
|
|
> "Remote pairing runs an ngrok tunnel from the internet to this machine's
|
|
> browser (locked to a 26-command allowlist + scoped token, but still an
|
|
> exposure). Enable pair-agent on this machine?"
|
|
|
|
Options: A) Enable — run `~/.claude/skills/gstack/bin/gstack-config set pair_agent on`, confirm it reads back `on`, and continue. B) No — stop here; local pairing (option A above) still works.
|
|
|
|
If the value is already `on`, say nothing and continue — consent stands until
|
|
`gstack-config set pair_agent off`.
|
|
|
|
Then detect ngrok status:
|
|
|
|
```bash
|
|
which ngrok 2>/dev/null && echo "NGROK_INSTALLED" || echo "NGROK_NOT_INSTALLED"
|
|
ngrok config check 2>/dev/null && echo "NGROK_AUTHED" || echo "NGROK_NOT_AUTHED"
|
|
```
|
|
|
|
**If ngrok is installed and authed:** Just run the command. The CLI will auto-detect
|
|
ngrok, start the tunnel, and print the instruction block with the tunnel URL:
|
|
|
|
```bash
|
|
$B pair-agent --client TARGET_HOST
|
|
```
|
|
|
|
Default access already includes JS execution. To also grant browser-wide
|
|
control (stop, restart, disconnect):
|
|
|
|
```bash
|
|
$B pair-agent --control --client TARGET_HOST
|
|
```
|
|
|
|
For a less-trusted agent, narrow the scopes instead:
|
|
|
|
```bash
|
|
$B pair-agent --restrict read --client TARGET_HOST # read-only
|
|
$B pair-agent --restrict "read,write" --client TARGET_HOST # no JS, no cookies
|
|
```
|
|
|
|
**CRITICAL: You MUST output the full instruction block to the user.** The command
|
|
prints everything between ═══ lines. Copy the ENTIRE block verbatim into your
|
|
response so the user can copy-paste it into their other agent. Do NOT summarize it,
|
|
do NOT skip it, do NOT just say "here's the output." The user needs to SEE the block
|
|
to copy it. Output it inside a markdown code block so it's easy to select and copy.
|
|
|
|
Then tell the user:
|
|
"Copy the block above and paste it into your other agent's chat. The setup key
|
|
expires in 5 minutes."
|
|
|
|
**If ngrok is installed but NOT authed:** Walk the user through authentication.
|
|
|
|
SECURITY: the ngrok authtoken must NEVER pass through this chat, a Bash tool
|
|
call, or shell history — a token pasted here lands in the transcript (and
|
|
anything the transcript syncs to). The user runs the auth command in their
|
|
OWN terminal; you only verify the result.
|
|
|
|
Tell the user:
|
|
"ngrok is installed but not logged in. Let's fix that — in your own terminal
|
|
(not here; the token should never enter this chat):
|
|
|
|
1. Go to https://dashboard.ngrok.com/get-started/your-authtoken
|
|
2. Copy your auth token
|
|
3. In YOUR terminal, run: ngrok config add-authtoken <paste your token>
|
|
4. Tell me 'done' when finished."
|
|
|
|
STOP here and wait for the user to say they've run it. Do NOT accept a pasted
|
|
token; if the user pastes one anyway, tell them to rotate it at
|
|
https://dashboard.ngrok.com (it's now in the transcript) and re-auth in their
|
|
terminal with the new one.
|
|
|
|
When they say done, verify without touching the token:
|
|
```bash
|
|
ngrok config check 2>/dev/null && echo "NGROK_AUTHED" || echo "NGROK_NOT_AUTHED"
|
|
```
|
|
|
|
If `NGROK_AUTHED`: retry `$B pair-agent --client TARGET_HOST`.
|
|
If still `NGROK_NOT_AUTHED`: ask them to re-run the command in their terminal.
|
|
|
|
**If ngrok is NOT installed:** Walk the user through installation:
|
|
|
|
Tell the user:
|
|
"To connect a remote agent, we need ngrok (a tunnel that exposes your local
|
|
browser to the internet securely).
|
|
|
|
1. Go to https://ngrok.com and sign up (free tier works)
|
|
2. Install ngrok:
|
|
- macOS: `brew install ngrok`
|
|
- Linux: `snap install ngrok` or download from ngrok.com/download
|
|
3. Auth it: `ngrok config add-authtoken YOUR_TOKEN`
|
|
(get your token from https://dashboard.ngrok.com/get-started/your-authtoken)
|
|
4. Come back here and run `/pair-agent` again."
|
|
|
|
STOP here. Wait for the user to install ngrok and re-invoke.
|
|
|
|
## Step 5: Verify connection
|
|
|
|
After the user pastes the instructions into the other agent, wait a moment then check:
|
|
|
|
```bash
|
|
$B status
|
|
```
|
|
|
|
Look for the connected agent in the status output. If it appears, tell the user:
|
|
"The remote agent is connected and has its own tab. You'll see its activity in the
|
|
side panel if you have GStack Browser open."
|
|
|
|
## What the remote agent can do
|
|
|
|
Default access is read+write+admin+meta. The trust boundary is the pairing
|
|
ceremony, not the scope:
|
|
- Navigate to URLs, click elements, fill forms, take screenshots
|
|
- Read page content (text, HTML, snapshot)
|
|
- Create new tabs (each agent gets its own)
|
|
- Execute JavaScript via `eval`
|
|
- Cannot stop or restart the browser, or disconnect headed mode (needs --control)
|
|
|
|
Remote agents go through the tunnel command allowlist: `eval` works, but the
|
|
`js`, `cookies`, and `storage` commands are not dispatchable over the tunnel
|
|
even with admin scope. Agents paired with `--local` get all four.
|
|
|
|
With --restrict (`--restrict read`, `--restrict "read,write"`):
|
|
- Sandboxed sessions: read-only, or read+write with no JS, cookie, or storage
|
|
access. Pair this way when the remote agent will read untrusted web content:
|
|
a trusted agent can be prompt-injected by pages it reads, and scope caps the
|
|
blast radius (eval works over the tunnel).
|
|
- `--restrict` never grants `control`; that scope stays behind --control.
|
|
|
|
With --control (--admin is the legacy alias):
|
|
- Everything, plus browser-wide destructive ops (stop, restart, disconnect)
|
|
- Only for agents you fully trust.
|
|
|
|
## Troubleshooting
|
|
|
|
**"Tab not owned by your agent"** — The remote agent tried to interact with a tab
|
|
it didn't create. Tell it to run `newtab` first to get its own tab.
|
|
|
|
**"Domain not allowed"** — The token has domain restrictions. Re-pair with broader
|
|
domain access or no domain restrictions.
|
|
|
|
**"Rate limit exceeded"** — The agent is sending > 10 requests/second. It should
|
|
wait for the Retry-After header and slow down.
|
|
|
|
**"Token expired"** — The 24-hour session expired. Run `/pair-agent` again to
|
|
generate a new setup key.
|
|
|
|
**Agent can't reach the server** — If remote, check the ngrok tunnel is running
|
|
(`$B status`). If local, check the browse server is running.
|
|
|
|
## Platform-specific notes
|
|
|
|
### OpenClaw / AlphaClaw
|
|
|
|
OpenClaw agents use the `exec` tool instead of `Bash`. The instruction block uses
|
|
`exec curl` syntax which OpenClaw understands natively. When using `--local openclaw`,
|
|
credentials are written to `~/.openclaw/skills/gstack/browse-remote.json`.
|
|
|
|
|
|
### Codex
|
|
|
|
Codex agents can execute shell commands via `codex exec`. The instruction block's
|
|
curl commands work directly. When using `--local codex`, credentials are written
|
|
to `~/.codex/skills/gstack/browse-remote.json`.
|
|
|
|
### Cursor
|
|
|
|
Cursor's AI can run terminal commands. The instruction block works as-is.
|
|
When using `--local cursor`, credentials are written to
|
|
`~/.cursor/skills/gstack/browse-remote.json`.
|
|
|
|
## Revoking access
|
|
|
|
To disconnect a specific agent:
|
|
|
|
```bash
|
|
$B tunnel revoke AGENT_NAME
|
|
```
|
|
|
|
The command deletes every token for that agent (the session and any pending
|
|
setup keys) and re-reads the agent list to prove it's gone.
|
|
|
|
See who's paired:
|
|
|
|
```bash
|
|
$B tunnel agents
|
|
```
|
|
|
|
Unexchanged setup keys show as "(pending)"; `tunnel revoke` removes them too.
|
|
|
|
To disconnect ALL agents at once, stop the daemon. Scoped tokens live in
|
|
daemon memory and never survive a restart; the next command boots a fresh
|
|
daemon with a new root token:
|
|
|
|
```bash
|
|
$B stop
|
|
```
|