[ion-alpha-dev]

What

Flynn now keeps a separate home for each external CLI under its data directory (claude/ and codex/) and runs the CLI against it, instead of copying the user's own credential (~/.claude/.credentials.json, or auth.json from ~/.codex or CODEX_HOME) into a per-run home for every episode. Flynn never reads, copies or stores the token inside.

Why

The user's personal sign-in belongs to their own use of the CLI, and Flynn had no reason to handle it. A copied token also lives outside the CLI's control: the CLI cannot refresh the original, and the copy sits in a directory the user never asked for. With a home of its own, each CLI signs in through its own login flow, keeps its token where it put it, and refreshes it in place.

How to verify

• go test ./cmd/flynn ./externagent
• TestDedicatedAuthDirIsWrittenInPlace: a home marked writable (SandboxConfig.AuthDirWritable) is used in place with nothing copied, and an unmarked home stays read-only.
• TestOwnHomeSpawnersGrantWriteOnTheirHome: the claude and codex envelopes set AuthDirWritable, AuthDir and the right environment variable.
• TestClaudeHomeIsFlynnsOwnAndNeverTheUsers, TestCodexHomeIsFlynnsOwnAndNeverTheUsers: each backend uses Flynn's home whatever the user's environment variable says, and the home exists before detection. The codex test also checks that config.toml, AGENTS.md and a skills directory are removed while auth.json is kept.
• TestExternalHomesAreOwnerOnly: an existing home with mode 0755 is 0700 once the spawner is built (the mode assertion is skipped on Windows, where permission bits do not express owner-only access).
• TestClaudeHomeKeepsOnlyItsSignIn: settings.json, CLAUDE.md, .claude.json and an agents directory are removed from the claude home and .credentials.json is kept.
• TestClearOwnHomeReportsAnUnreadableHome, TestClearOwnHomeReportsAnUnremovableEntry, TestExternalSpawnerRefusesAHomeItCannotPrepare, TestEnsureOwnHomeReportsAFailure: the non-ENOENT error paths.
• TestLoginSignsInFlynnsHome: the sign-in message for both backends names the right variable and login command, quotes the path for sh and PowerShell, and never asks for an API key.
• By hand: run flynn --model codex (or claude) with no sign-in; it prints a CODEX_HOME=... codex login (or CLAUDE_CONFIG_DIR=... claude auth login --claudeai) command. After running it, the backend reports itself ready and ~/.codex / ~/.claude are unchanged.

Notes for reviewers

• Anyone already using --model claude or --model codex signs in once more. Their own ~/.claude and ~/.codex sign-ins are untouched.
• The user's own settings, hooks, MCP servers and config.toml are never on the child's path. The child may write Flynn's codex home, so before a spawner is built everything in that home except auth.json is removed (config, AGENTS.md, prompts, skills, history, caches); the CLI recreates what it needs. The claude home gets the same treatment through the shared clearOwnHome, keeping only .credentials.json: settings.json (hooks, permission allow rules), CLAUDE.md, agents/, commands/, plugins/ and .claude.json are removed. With CLAUDE_CONFIG_DIR set, Claude Code keeps .claude.json in that directory, and it holds user-scoped MCP servers and trust decisions, so it cannot be kept; the account details in it are re-read from the token. I did not run the claude CLI against a cleared home to confirm its status check still reports signed in, so that is worth confirming by hand. A sign-in held in the OS keyring is outside the home and untouched. MkdirAll leaves an existing directory's mode alone, so both homes are chmod to 0700 explicitly.
• The PowerShell branch of homeLoginCommand has no Linux CI coverage because it is selected by runtime.GOOS == "windows", and codecov uploads the Linux coverage profile. The Windows test job does run TestLoginSignsInFlynnsHome, which asserts the quoted path and the trailing Remove-Item. The branch is two lines of string concatenation, and no Linux test can reach it without making the OS a parameter.
• Uncovered lines expected in the Linux patch report: the os.Chmod failure return in ensureOwnHome. It can only fail after MkdirAll succeeded on the same path (a race with another process or a filesystem that refuses chmod), so there is no portable way to provoke it. The RemoveAll failure return in clearOwnHome and both spawners' clear failures are covered on Linux and skipped on Windows and as root, because directory permissions do not block removal there.

[codecov]

Codecov Report

❌ Patch coverage is 95.45455% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
cmd/flynn/externagent.go	95.16%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[ion-alpha-dev]

Review: the change is right, and no token copy path is left. Four things to fix before merge:

1. MkdirAll(0o700) does not tighten a directory that already exists. If <dataDir>/claude or <dataDir>/codex was created earlier with a wider mode, it keeps that mode. Chmod after creating, and add a test that asserts 0700.
2. The child can write the codex home (AuthDirWritable: true), but clearCodexConfig removes only config.toml. A run could leave behind AGENTS.md, prompts or skills that steer the next run. Either clear everything except the auth files, or document the remaining risk beside clearCodexConfig.
3. No test asserts that AuthDirWritable: true is set in the claude and codex spawner configs. Add one so a regression fails CI.
4. The non-ENOENT error return in clearCodexConfig needs a test (make config.toml a non-empty directory). The PowerShell branch of homeLoginCommand runs only on Windows, so a sentence about it in the PR body covers it.

go test -race ./externagent/... ./cmd/flynn/... passes locally.

[ion-alpha-dev]

Second review: the codex fixes are good. The claude home still has the problem that was fixed for codex. claudeSandboxConfig grants the episode write on <dataDir>/claude (AuthDirWritable: true), but nothing clears that home between runs. Claude Code reads settings.json (hooks, permission allow lists), CLAUDE.md (user memory), agents/, commands/ and plugins/ from CLAUDE_CONFIG_DIR. A harness could write any of them and steer every later claude run. --strict-mcp-config neutralizes only the MCP servers. The claudeHome doc comment says "the worst a harness can do there is sign Flynn's copy out", which is not true while that holds.

Please clear the claude home the same way: keep only the sign-in (.credentials.json, plus .claude.json if the CLI reports itself unusable without its onboarding and account state) and remove everything else before the spawner is built. Share the code with clearCodexHome (one function over a keep-set), test it with settings.json, CLAUDE.md and an agents directory, and correct the comment.