Skip to content

v1.68.2.0 fix: tunnel revoke exists and revokes everything — setup keys included, verified live - #2646

Merged
garrytan merged 7 commits into
mainfrom
fix/tunnel-revoke-all
Aug 20, 2026
Merged

garrytan merged 7 commits into
mainfrom
fix/tunnel-revoke-all

Conversation

@garrytan

Copy link
Copy Markdown
Owner

Why (in your own words)

Revoking a paired agent was a lie twice over. revokeToken deleted only the first Map entry for a clientId, and the spent setup key kept for connection retries always sat first in line: DELETE /token/<agent> returned 200 while the live session kept driving the browser, a leftover unspent setup key could mint a brand-new session for a "revoked" agent inside the key's 5-minute window, and a second DELETE returned 200 again. The documented way out, $B tunnel revoke, did not exist — the CLI forwarded it to the daemon as Unknown command: 'tunnel'. And the pairing docs still promised a read+write sandbox ("Cannot execute arbitrary JavaScript, read cookies, or access storage") three releases after b73f364 deliberately made pairing full-access, so a user following the skill believed they granted a sandboxed session and actually granted JS execution on their logged-in browser.

This PR makes revocation total and verified, makes the documented CLI real, pins the pairing default in one shared constant, and rewrites the docs to the truth. Along the way it closes four adjacent traps found during review: bare --restrict silently granted FULL access (the opposite of intent), a scopes list could smuggle in the control scope, scope typos surfaced as a misleading error to the remote agent at /connect, and rateLimit: 0 (documented "unlimited") silently became 10 on the /pair path.

Live evidence

BEFORE — origin/main @ 9da6692, BROWSE_HEADLESS_SKIP=1 daemon, mallory paired + connected, second setup key pending:

$ DELETE /token/mallory
HTTP 200
$ GET /agents
{"agents":[{"clientId":"mallory","scopes":["read","write","admin","meta"],...}]}   # still listed
$ POST /command with the 'revoked' token
HTTP 403                                                                            # NOT 401 — token still authenticates
$ POST /connect with the leftover setup key (within its 5-min window)
{ "token": true, "scopes": ["read","write","admin","meta"] }                        # new session minted post-revoke
$ DELETE /token/mallory (second call)
HTTP 200                                                                            # false 200, again

AFTER — this branch, same ceremony:

$ browse tunnel agents
mallory  scopes=read,write,admin,meta  domains=any  expires=2026-08-21T04:04:40.869Z  commands=0
mallory  (pending setup key)  scopes=read,write,admin,meta  domains=any  expires=2026-08-20T04:09:40.872Z  commands=0
$ browse tunnel revoke mallory
Revoked "mallory" (3 tokens).
Verified: not in the active agent list.
$ GET /agents
{"agents":[]}
$ POST /command with the revoked token
HTTP 401
$ POST /connect with the leftover setup key
HTTP 401
$ browse tunnel revoke mallory (second call)
No paired agent named "mallory".
No agents are currently paired.
exit: 1
$ POST /pair with a scope typo
{"error":"Invalid scope: raed. Valid: read, write, admin, meta, control"}
$ POST /pair smuggling control in scopes
{"error":"The control scope requires the control flag (--control); it cannot be granted via a scopes list."}

Fail-first: the shape a/b regression tests run against origin/main fail (0 pass, 2 fail — session survives revoke; leftover key re-connects); on this branch the committed versions pass.

(fail) fail-first: revoke-all shapes on origin/main > shape a: revoke kills the session shadowed by a spent setup key
(fail) fail-first: revoke-all shapes on origin/main > shape b: unspent setup key dies with the revoke (no re-grant)
 0 pass
 2 fail

Targeted suite on the branch: bun test browse/test/token-registry.test.ts browse/test/pair-agent-e2e.test.ts browse/test/tunnel-revoke-cli.test.ts browse/test/server-auth.test.ts browse/test/tab-isolation.test.ts browse/test/skill-token.test.ts → 178 pass, 0 fail. bun run gen:skill-docs --host all → zero drift. bun run build → clean.

Scope

  • Changed: browse/src/token-registry.ts (revoke-all + count, DEFAULT_PAIR_SCOPES, InvalidScopeError, shared option validation, listTokens({includeSetup}), invariant comment), browse/src/server.ts (/pair control gate + typed 400s, /agents pending keys, DELETE /token decode + tokens_deleted, 403 hint), browse/src/cli.ts (tunnel revoke/tunnel agents with post-revoke verify, validatePairAgentFlags, explicit scopes), browse/src/skill-token.ts (Boolean wrap), docs (pair-agent/SKILL.md.tmpl + regenerated SKILL.md, docs/REMOTE_BROWSER_ACCESS.md, ARCHITECTURE.md), tests (35 new cases incl. a subprocess CLI harness with stub daemons pinning the version-skew net and every CLI error branch), VERSION/CHANGELOG.
  • Verified live by: the before/after transcript above, the fail-first run on origin/main, the 178-test targeted loop, the gen-skill-docs drift gate, bun run build, and a pre-push adversarial review (4 lenses, refute-style verification: 13 raw findings, 7 refuted, 6 confirmed and fixed in the final commit — including an --restrict=read equals-form bypass of the new validation).
  • Did NOT test: the live ngrok tunnel path (needs an authtoken; the tunnel allowlist code is unchanged — TUNNEL_PATHS still /connect + /command). The full free suite in my sandbox has pre-existing environment failures OUTSIDE browse/ (relink/session-update/skill-validation fail identically or worse on untouched origin/main there — missing file binary, symlink collisions with a live gstack install); all browse/ shards pass locally, and the authoritative full run is this PR's free-tests.yml lane.

Notes for the reviewer:

  • The "Revocation incomplete" CLI branch doubles as a deliberate version-skew net: a NEW CLI pointed at a still-running OLD daemon (first-match revoke bug) gets caught by the post-revoke /agents re-read, exits 1, and suggests re-running (which converges on old daemons) or stop. Pinned by a stub-daemon test.
  • POST /token (root direct mint) intentionally still accepts explicit control in scopes — root minting explicit scopes is the deliberate path; only the /pair ceremony gates it behind the control flag.
  • The re-grant hole is time-boxed by the setup key's 5-minute expiry; the transcript's leftover-key step ran inside that window.

Liveness proof (required)

Maintainer-authored PR, prepared by Claude Code in a cloud sandbox at the owner's request — there is no human screen in the loop to photograph. @garrytan: attach a GSTACK PR screenshot from your machine if you want the ritual observed for maintainer PRs, or waive it.

Checklist

  • Liveness screenshot attached: GSTACK PR typed live into a real surface (owner to attach or waive — see above)
  • This is not a generated-file-only diff (I edited the source/template and regenerated)
  • No ETHOS.md edits, and no changes to voice / founder perspective / YC references
  • New public command / external service / host adapter has an accepted issue linked (or N/A — tunnel revoke/tunnel agents implement the already-documented CLI surface)
  • Linked issue or reproduction: reported against 1.60.1.0 by the maintainer; reproduction transcript above

🤖 Generated with Claude Code

garrytan and others added 7 commits August 20, 2026 03:48
…irst 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>
`$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>
…_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>
…h 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 b73f364 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>
…eal 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>
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>
…ion-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>
@trunk-io

trunk-io Bot commented Aug 20, 2026 •

Copy link
Copy Markdown

😎 This pull request was merged.

@github-actions

Copy link
Copy Markdown
Contributor

E2E Evals: ✅ PASS

8/8 tests passed | $1.48 total cost

Suite Result Status Cost
e2e-browse 2/2 ✅ $0.16
e2e-deploy 2/2 ✅ $0.36
e2e-qa-workflow 1/1 ✅ $0.58
llm-judge 1/1 ✅ $0.02
e2e-deploy 2/2 ✅ $0.36

ubicloud-standard-8 runners (Docker: pre-baked toolchain + deps) | wall clock ≈ slowest suite

@garrytan
garrytan merged commit 51932ec into main Aug 20, 2026
29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant