fleetd/AUDIT.md

Spawn-boundary audit — member/ launchers

Scope: fleetd/src/main/java/dev/ltms/fleet/member/ (ClaudeCodeLauncher, OpenCodeLauncher, HerdrPeerLauncher, CompositePeerLauncher, EnvAllowListScrub, MemberEnvAllowList, MemberCredentialPolicyView, OpenCodeSessionDiscovery). No worker/ package exists — the launcher classes live entirely under member/, so I read that whole directory instead.

Main finding

1. fleetd/src/main/java/dev/ltms/fleet/member/ClaudeCodeLauncher.java:548-632 (seedTrustDialog)

Issue. seedTrustDialog writes the workspace-trust seed to configDir/.claude.json, or to ~/.claude.json (fleetd's own user.home) when configDir is unset. It gates only on isProvisionedWorktree(cwd) (line 549). It never checks memberHerdrSocketConfigured() and, being a static method, cannot reach that instance state even if it wanted to.

Compare this to its sibling in the very same class, writeCharterFile (line 788, an instance method): that one explicitly checks memberHerdrSocketConfigured() (line 790) and, when true, routes the file under memberScrubParentDir() (worktreeRoot) and calls EnvAllowListScrub.shareWithGroup(dir, group) (line 813) — or refuses the spawn outright when worktreeRoot/worktreeGroup isn't configured (lines 798-807), rather than hand the member a path its OS user cannot read. OpenCodeLauncher.writeConfig/configParentDir (lines 422-508, 542-559) do the identical thing for opencode.json. seedTrustDialog is the one cross-process, member-facing file write in this class that skips that treatment entirely.

It also makes the miss worse on its own: writeAtomically (line 696) calls copyPosixPermissionsIfPresent (line 710), which deliberately preserves the existing file's POSIX permissions — and Claude Code ships .claude.json at 0600 (see the javadoc at line 681). So even where configDir happens to point at an already-shared directory, the seeded file itself is written owner-only, unreadable by a different OS user.

Spawn path that reaches it. Any claude profile that (a) sets memberHerdrSocket: (real, validated config — see memberHerdrSocketConfigured() at HerdrPeerLauncher.java:1667) and (b) does not set configDir:, spawned with worktree:true (so isProvisionedWorktree(cwd) is true and the method proceeds). buildLaunch calls seedTrustDialog(cfg.configDir(), spec.cwd()) unconditionally at line 290, before the pane is ever created.

What goes wrong. Under that config, seedTrustDialog writes the trust entry into fleetd's own ~/.claude.json — the daemon's OS user's home. But the actual Claude Code process starts under the member's different OS user (that's the whole point of memberHerdrSocket), with its own $HOME, and (with configDir unset) reads ~/.claude.json relative to that home — a file this method never touches. The seed lands nowhere the spawned process will ever look. The result is exactly the fleetd #149 incident this method exists to prevent: the member sits on Claude Code's interactive, un-timed "Is this a project you trust?" dialog forever, never mounts the bridge MCP, and never calls fleet_reply; the CB-306 spawn-readiness gate eventually times it out as an unexplained "did not reach injectable state."

Confidence. High that the code path is exactly as described — I traced buildLaunch → seedTrustDialog → writeAtomically/copyPosixPermissionsIfPresent directly, and confirmed writeCharterFile's contrasting memberHerdrSocketConfigured() gate at the same class's line 790. Medium on operational reachability today: several javadocs elsewhere in HerdrPeerLauncher describe "memberHerdrSocket ABSENT" as "today's only live mode," so this gap may not be hit by the currently-deployed fleet — but it is a real, config-reachable hole in a feature the codebase otherwise treats as first-class (four other defects fixed for exactly this seam: fleetd #213, #219, #222 in this same file/its sibling). Direction of harm: an operator who turns memberHerdrSocket on gets a silently-hung claude member instead of a working one — no data loss, no credential leak, but a resource stuck occupying a pane with no diagnosis pointing at the real cause (this is the "silent" failure mode the class's other methods were deliberately rewritten to avoid).

Secondary findings

2. fleetd/src/main/java/dev/ltms/fleet/member/ClaudeCodeLauncher.java:788-818 (writeCharterFile) and OpenCodeLauncher.java:422-508 (writeConfig)

Both create a per-spawn temp file/directory (role+reply charter file; opencode.json + member-charter + IDE-rules files) and rely only on deleteOnExit for cleanup. Unlike the CB-633 ZDOTDIR directory, which spawnInternal (HerdrPeerLauncher.java:519-528) explicitly deletes with EnvAllowListScrub.deleteRecursively(zdotdir) when spawnInTab/spawnAsPane throws after buildLaunch succeeded, nothing tears down the charter file or the opencode config directory on that same failure path — they leak until JVM exit, which for a long-running daemon can be effectively never. Symmetric between the two launchers (not an asymmetry), so it is secondary, but it is the same "created at spawn, not cleaned up if spawn then fails" shape the brief called out. Confidence: high that the code omits it (read both methods and the spawnInternal catch block); low-medium severity — disk clutter in a temp/worktree-scrub directory, not a security or correctness issue on the member itself.

3. Shape noted, not investigated. ClaudeCodeLauncher.writeIdeOverlay (line 438) also skips memberHerdrSocketConfigured(), but unlike seedTrustDialog it writes into cwd itself (the worktree root), which — if worktree provisioning already shares the worktree with the member's OS user under worktreeGroup (plausible, but I did not verify the worktree-provisioning code, which is outside this scope) — would already be readable/writable by the member without any extra routing. Flagging the shape rather than a finding since I have not confirmed worktree provisioning outside member/.

Out of scope, noted only

• The worker/ directory named in the brief does not exist; all launcher classes live in member/, which I reviewed in full instead.
• Worktree-provisioning permissions (whether worktreeGroup sharing actually covers cwd) live outside this package and were not verified.