Drive Claude Code on the web instead of the CLI (MVP shortcut: free worktrees + PR, 0% local CPU)

[suleimansh]

Captured from team discussion. Flagged as a potentially large MVP shortcut. The mechanism (how we drive it) and session/login are open; needs a spike.

Idea

Add a driver that uses Claude Code on the web instead of the Claude Code CLI. We drive the web UI programmatically and let it run the task, rather than running the CLI locally.

Why it's a big shortcut

• Claude Code on the web already does the whole Git worktree dance and opens the GitHub PR. We reuse that flow instead of building it (relates to Git worktrees #453).
• It runs off the user's machine: roughly 0% local CPU, so AI tasks parallelize essentially without limit.
• It is where at least some of us already work day to day.

How to drive it (open)

• Chrome extension: the first idea. Simple-ish, but an install plus configuration.
• Headless browser automation: drive the web UI in a server-side headless browser (no install, seamless). Could reuse the headless-streaming primitive from the preview capability (Preview: stream the agent's headless browser so a human can step in when it's blocked #609), though the purpose is different (driving the agent vs previewing the agent's browser).
• Decision pending; a spike should compare the two on the hard part below.

The one hard part: session / login

• Confirm we can drive an authenticated Claude Code web session programmatically (headless or via extension). This is the main unknown and likely decides extension vs headless.

Related

• Epic: Bring your own subscription (BYOS) — run the user's own coding-agent CLI #495 (BYOS): the CLI path for "use the user's own agent". This is the web analog.
• Git worktrees #453 (git worktrees): the web flow does this for us, reducing what we build.
• Preview: stream the agent's headless browser so a human can step in when it's blocked #609: a separate idea, but shares the possible headless-browser mechanism.
• Epic: Daemon + gateway split — headless 24/7 runtime, composable frontend #605 (daemon): where a server-side headless driver would run.

[suleimansh]

Spike: drive Claude Code on the web

Recommendation: neither extension nor headless. Use the routines fire API. Both browser options script an authed claude.ai page to reinvent an API Anthropic already ships, and both are barred by the Usage Policy. The API needs no browser and no new auth beyond a per-routine token.

The hard part (session / login): answered

Yes, an authenticated web session is drivable programmatically, without cookies or anti-bot. Two official paths, both on the same claude.ai subscription the CLI already holds:

• Routines fire API POST /v1/claude_code/routines/{trig_id}/fire, bearer token sk-ant-oat01-... (per-routine, made once in the web UI), beta header experimental-cc-routine-2026-04-01. Returns {claude_code_session_id, claude_code_session_url}. Plain HTTP, no TTY. This is the programmatic path.
• claude --cloud "<task>": the terminal path, not a driver. Verified (v2.1.211): run non-interactively (piped stdout) it exits 1, --cloud requires an interactive terminal ... would silently ignore --cloud. That is exactly the mode ClaudeCodeDriver uses, so --cloud can't sit behind the non-interactive driver without a PTY + TUI-scrape. Hence the API.

Docs: routines fire · --cloud / --teleport

Driver-seam fit

A WebDriver fits the seam, with one real change: the web flow is fire-and-forget, so prompt resolves with the session handle (id + url), not a final turn.

• start holds the routine id + token. prompt POSTs /fire and returns the handle. readCode omitted (remote VM). dispose no-op.
• Collect the outcome later off the pushed branch / PR (or --teleport). We gate on the code, which is what the seam already says.

Free from the web flow: per-session worktree + branch (#453), the PR, and parallel sessions at ~0% local CPU. We own: firing, tracking session ids, collecting + gating. The daemon (#605) is the natural host for that fire-then-collect loop.

PoC: draft PR #623 (spike/610-web-driver) implements this, injectable fetch, 7 unit tests green.

ToS (this is what decides it)

"You may not access Claude through automated or non-human means ... except when you are accessing our Services via an Anthropic API Key or where we otherwise explicitly permit it."

Plus, as of 2026-04-05, third-party agents using claude.ai subscription credentials are banned. So driving the UI (extension/headless) is prohibited; the routines API and --cloud are explicitly permitted (Anthropic's own API/CLI, same footing as BYOS #495). Other limits: web is research preview (Pro/Max/Team/Enterprise); no API-key auth, no Bedrock/Vertex/Foundry, no ZDR orgs. The API is experimental, fire-and-forget, no read-back, not idempotent, per-account daily cap.

Next step

1. Make a routine + token in the web UI, point PR spike(#610): WebDriver PoC on the routines fire API #623 at it for one live /fire.
2. Decide the async contract (prompt resolves on session-created, not final turn). That's the one seam change; spike(#610): WebDriver PoC on the routines fire API #623 stays draft, changeset lands, once it's settled.

[brillout]

• Let's always toggle Auto (see Mode in the UI of claude.ai/code)
• How about we select all TF repositories by default (let's see if TF's Context prompt injection does the trick, I think so)
• We need a way to forward settings such as the model (see also: Select Model #628)