feat: sign in to a backend from codeoid, instead of pasting an API key

[saucam]

Settings → Claude → Sign in with Claude. Open the link, paste back the code, done — no API key.

The gap

Every backend codeoid runs already has a first-party login that mints a subscription credential — claude setup-token, codex login, qwen's OAuth. Each is an interactive terminal command, so using one meant having a shell on the machine the daemon runs on. When codeoid is the whole surface — a hosted sandbox, a phone — nobody does, and an API key was the only way in.

The gap was never that login is impossible. It was that it was unreachable from the only UI the user has.

Brokering, not reimplementing

The daemon runs the vendor's own command. It does not implement anyone else's OAuth.

That distinction is the design, not an implementation detail. Scraping a client id out of someone's CLI and driving their token endpoint ourselves works right up until they change it, and puts us in the business of maintaining another company's auth. Running the command they ship means their flow can change under us and keep working.

Two steps, because that is the shape their commands already have:

1. backend.login.start — run the command, return the authorize URL it prints. The user opens it in their browser. The daemon never needs one, which is what makes this work headless.
2. backend.login.submit — the vendor's callback page displays a code; the user pastes it back; the daemon hands it to the still-waiting command.

No new dependency. The claude binary is already in node_modules — the Agent SDK's platform package (@anthropic-ai/claude-agent-sdk-<platform>) ships it, and it is what every Claude turn already runs through. So this adds no image bytes and by definition exists wherever the Claude backend works. Verified end to end against it: real setup-token, real PKCE authorize URL, 4.5s.

The awkward part is the terminal

These commands are TUIs. claude setup-token writes nothing at all to a pipe — it detects the absence of a TTY and waits forever (verified: zero bytes, hung). Under a pty it prints its URL in under two seconds.

So it needs a pty, and codeoid has no pty dependency — node-pty is a native module, i.e. a build toolchain in every image for one feature. script(1) is the pty: util-linux on Linux (Essential, so present even in debian-slim), BSD script on macOS, a different argv on each.

What comes back is raw terminal output: ANSI, OSC-8 hyperlinks, spinner redraws, an 80-column wrap that chops the URL across lines. Rather than strip escapes and hope, every pattern matches on a character class that terminal control bytes cannot appear in — so the escapes are simply not matchable — and longest-match wins, which is what picks the hyperlink's unwrapped copy of the URL over the visible truncated one.

What the tests found

They run a fake vendor command through the real pty and the real matchers, because the parts likely to be wrong here are not the state machine but the seam with a terminal — whether script is invoked right, whether the URL survives the hyperlink and the wrap, whether writing a line to stdin reaches a program blocked on read. Mocking the process would test the half that was never in doubt.

That caught a bug worth naming: a pty echoes its input, so a user who pastes something credential-shaped (the exact mistake made when "code" is confused with "key") had their own typo read back as the vendor's answer — success reported, garbage stored. Nothing a vendor returns for an exchange is a substring of the code that requested it, and that is now the rule. Containment rather than equality, because a wrapped echo can match as a prefix.

Storage, scope, hygiene

• Ordinary settings path. The credential lands in the same 0600 .env, shows as set in the same snapshot, and is cleared by the same control as one that was typed. A credential the UI can create but not show or revoke is one nobody can reason about.
• settings:write, not a new scope. A completed login writes to the same file that scope already governs; a separate scope would imply a privilege boundary that does not exist, and cost a token migration to express.
• The submitted code and the resulting credential are never logged, never echoed to a client, never in an error. The transcript is dropped when the attempt ends.
• One attempt per backend, superseded on restart (so a reloaded page is not locked out by its own abandonment), killed by process group on cancel and on daemon drain — killing script alone would orphan the command it wrapped.

Not in scope

claude login on a machine with a shell still works and is still picked up; nothing here replaces it. Only Claude is wired — codex, gemini and qwen are a LoginFlow entry each, filed separately rather than guessed at, since each one's terminal output has to be read before its patterns can be written.

Verification

• bun run test — 2486 pass, 0 fail (26 new, in src/tests/backend-login.test.ts)
• bun run test:web — 509 pass (7 new, in web/src/state/backend-login.test.ts)
• bun run typecheck (root + protocol + core) and web/ tsc --noEmit — clean
• bun run lint — clean; web/ eslint — no new warnings
• Manual: real claude binary resolved from the SDK platform package, setup-token driven under the pty, authorize URL returned with code_challenge / code_challenge_method=S256 / state intact