[Bug] Tests that spawn daemon subprocesses fail when run from inside an agent session (worker env and color flags leak via process.env)

[ruttybob]

Affected area: Coding agent and CLI (test infrastructure)

What happened?

Running the test suite from inside a prime-agent session — i.e. asking an agent to run vitest, which is this repo's own documented workflow (AGENTS.md instructs agents to run tests from the package root) — makes 20 tests fail deterministically across 4 files, in two distinct modes:

File	Failures	Mode
test/daemon-supervisor-process.test.ts	9 / 17	connectEventually handshake timeout
test/suite/regressions/4685-daemon-client-modes.test.ts	9	stderr cleanliness assertions fail
test/suite/regressions/4600-supervisor-singleton.test.ts	1	handshake timeout (replacement supervisor)
test/suite/regressions/4606-update-restart-coordinator.test.ts	1	handshake timeout

Typical failure:

Error: Timed out waiting for supervisor: Error: Timed out after 1000ms
waiting for the Prime Agent daemon handshake. Socket: /var/folders/.../supervisor.sock

or:

AssertionError: expected '...' to be ''
+ (node:81138) Warning: The 'NO_COLOR' env is ignored due to the 'FORCE_COLOR' env being set.

Steps to reproduce

1. Start an interactive prime-agent session (any repo; the agent worker process env then contains PRIME_AGENT_INTERNAL_DAEMON_WORKER=1, PRIME_AGENT_INTERNAL_DAEMON_WORKER_TOKEN, PRIME_AGENT_INTERNAL_DAEMON_SUPERVISOR_SOCKET, PRIME_AGENT_INTERNAL_DAEMON_WORKER_RECOVERY_JOURNAL, PRIME_AGENT_INTERNAL_ORPHAN_PROCESS_JOURNAL, SESSION_LEASES_*, RLM_DEPTH, and both NO_COLOR=1 and FORCE_COLOR=1).
2. From that session run:

   cd packages/coding-agent
   npx tsx ../../node_modules/vitest/dist/cli.js --run test/daemon-supervisor-process.test.ts
   

3. Observe all 9 non-skipped tests time out connecting to the spawned supervisor.

Minimal form: any spawn(cli.ts, ["--mode", "daemon", ...], { env: { ...process.env } }) from a worker-env parent reproduces it. CI and plain shells never see it because the parent env is clean there.

Expected behavior

Tests that spawn a root daemon subprocess should boot it as a root daemon regardless of what env the test runner itself inherited; stderr-cleanliness assertions should not see warnings caused by the runner's own conflicting color flags.

Why this is a genuine deterministic failure, not flakiness or environment noise

1. Deterministic cause-and-effect at the protocol level. The agent worker env includes PRIME_AGENT_INTERNAL_DAEMON_WORKER=1. AgentDaemon.handleConnection() picks transport: "private-framed" when the daemon runs as a worker. Test helpers (spawnSupervisor in daemon-supervisor-process.test.ts, spawnRealSupervisor in 4600-supervisor-singleton.test.ts, spawnSupervisor in 4606-update-restart-coordinator.test.ts) spread ...process.env verbatim, so the spawned "root" daemon silently boots in worker mode: it binds the socket and accepts connections, but every outbound frame is private-framed — the jsonl DaemonClient never sees daemon_hello and times out. A raw socket probe during reproduction confirmed it: a daemon spawned with the inherited env answers connect with {"kind":"outbound","outboundType":"daemon_hello","payloadEncoding":"jsonl"} wrapped in a binary private-frame header. Fails every run from a worker env; passes every run from a clean shell.
2. Reproduces on pristine upstream. Verified in a fresh worktree checked out at tag v0.7.3 (61131b2d1), no local changes — daemon-supervisor-process.test.ts fails identically; the other three files fail through the same env-inheritance path.
3. The leak class is already acknowledged in production code. Spawning a fresh root daemon strips exactly these variables in three places: daemon-mode.ts (supervisor respawn deletes DAEMON_WORKER_ROLE_ENV, DAEMON_WORKER_TOKEN_ENV, DAEMON_WORKER_ACTIVE_SESSION_ID_ENV, DAEMON_WORKER_RECOVERY_JOURNAL_ENV, DAEMON_WORKER_SUPERVISOR_SOCKET_ENV, ORPHAN_PROCESS_JOURNAL_ENV, SESSION_LEASES_ENABLED_ENV, SESSION_LEASE_OWNER_ID_ENV), daemon-launch.ts (~line 361), and daemon-update-restart.ts (~line 521). fix(coding-agent): keep daemon root sessions at depth zero #1496 (e85a67ac4) added delete workerEnvironment.RLM_DEPTH to DaemonSupervisor for the same reason. The test helpers are the only CLI spawn sites without that sanitization.
4. The failing tests are real protocol-mode failures. The spawned daemon genuinely boots in the wrong mode (worker instead of root); the timeout is the symptom, not the bug.

The 4685-daemon-client-modes failures are a second, independent leak: agent sessions export both NO_COLOR=1 and FORCE_COLOR=1, so Node prints a warning to the stderr of every child process, breaking expect(result.stderr).toBe("") style assertions. (Side observation: should the product set both flags at once? That may deserve its own fix — but tests spawning subprocesses shouldn't be sensitive to the runner's color config either way.)

Prime Agent version: v0.7.3 (61131b2d1), still present on main (20b54977a)

Environment: macOS 26.5.1; Node v22.23.2; vitest 4.1.10

Additional context

Fix implemented and verified on our fork (ruttybob/prime-agent, branch dev-dogfood, commit 8e8d26027):

• New helper packages/coding-agent/test/daemon-spawn-env.ts exporting createRootDaemonEnv(overrides): copies process.env, deletes the eight worker/lease variables plus RLM_DEPTH, then applies overrides — so tests that deliberately pass RLM_DEPTH: "1" (the fix(coding-agent): keep daemon root sessions at depth zero #1496 regression test) still can.
• Applied in daemon-supervisor-process.test.ts, 4600-supervisor-singleton.test.ts, 4606-update-restart-coordinator.test.ts; color flags dropped in 4685-daemon-client-modes.test.ts (runCli/runRpc).
• Result: all affected files green when run from inside an agent session (166 passed / 8 skipped) and semantically unchanged for clean runners (the deleted variables are simply absent there). Mirrors the production cleanup list, so it cannot drift from what the daemon itself does.

Happy to open a PR if the direction looks right.

[ruttybob]

Fix details with exact locations (fork ruttybob/prime-agent, dev-dogfood, commit 8e8d26027):

New helper — packages/coding-agent/test/daemon-spawn-env.ts:17

export function createRootDaemonEnv(overrides: NodeJS.ProcessEnv = {}): NodeJS.ProcessEnv {
	const env: NodeJS.ProcessEnv = { ...process.env };
	delete env[DAEMON_WORKER_ROLE_ENV];
	delete env[DAEMON_WORKER_TOKEN_ENV];
	delete env[DAEMON_WORKER_ACTIVE_SESSION_ID_ENV];
	delete env[DAEMON_WORKER_RECOVERY_JOURNAL_ENV];
	delete env[DAEMON_WORKER_SUPERVISOR_SOCKET_ENV];
	delete env[ORPHAN_PROCESS_JOURNAL_ENV];
	delete env[SESSION_LEASES_ENABLED_ENV];
	delete env[SESSION_LEASE_OWNER_ID_ENV];
	delete env.RLM_DEPTH;
	return { ...env, ...overrides };
}

Sanitize first, then apply overrides — so a test can still deliberately pass RLM_DEPTH: "1" (the #1496 regression test at test/daemon-supervisor-process.test.ts:299 does exactly that, and passes with this change).

Applied at the three worker-env spawn sites:

• test/daemon-supervisor-process.test.ts:92 — spawnSupervisor()
• test/suite/regressions/4600-supervisor-singleton.test.ts:176 — spawnRealSupervisor()
• test/suite/regressions/4606-update-restart-coordinator.test.ts:56 — spawnSupervisor()

Color flags — test/suite/regressions/4685-daemon-client-modes.test.ts:

• :87-88 — runCli() sets NO_COLOR: undefined, FORCE_COLOR: undefined (alongside the worker-env undefineds it already had)
• :121-127 — runRpc() deletes both before spawning the RPC fixture

Why this mirrors production rather than inventing a new list: the exact same variables are already stripped where production code spawns a root daemon —

• src/modes/daemon/daemon-mode.ts:848-855 (supervisor respawn)
• src/cli/daemon-launch.ts:361
• src/cli/daemon-update-restart.ts:521
• src/modes/daemon/daemon-supervisor.ts:2197 (delete workerEnvironment.RLM_DEPTH, fix(coding-agent): keep daemon root sessions at depth zero #1496)

The transport flip the tests were hitting is src/modes/daemon/daemon-mode.ts:3285: transport: this.options.worker ? "private-framed" : "jsonl". The variables above are what feed options.worker, so deleting exactly them (no more) keeps the test env definitionally in sync with what the daemon itself considers worker-identifying state.

Net diff: 4 files changed, 45 insertions(+), 7 deletions(-), plus the 29-line helper. All previously failing tests pass when run from inside an agent session; clean-shell runners see no semantic change (the deleted variables are absent there).

[breedx]

Confirming this from a different environment, and offering a containment measure that composes with your fix rather than replacing it.

We run a soft fork of prime-agent and hit the same class on Linux (Ubuntu 24.04.4, Node 25.9) — so it is not macOS-specific. Our symptom was worse than failing tests: npm test from inside an agent session found the live daemon the agent was running in and killed it mid-session. The workspace test script is bare vitest --run with no exclusions, so it picks up daemon-supervisor-process.test.ts, which does process.kill(pid, "SIGKILL"), process.kill(-pid, "SIGTERM") on a process group, and shutdown --force — whose stated job is removing "hidden supervisors and workers". Upstream already knows, since test:ci exists specifically to --exclude that file; the trap is that AGENTS.md points agents at the package root, where the unexcluded script is what they get.

Your diagnosis explains the failures precisely, and the createRootDaemonEnv helper is the right shape — it mirrors the production cleanup list, so it cannot drift from what the daemon itself does. Two things we found that may be worth folding in:

1. Process reach is containable today, with no code change. An unprivileged PID namespace makes the host daemon's PID not exist for the test process, so a stray kill physically cannot land:

SANDBOX=$(mktemp -d /tmp/prime-test-XXXX)
unshare --user --map-root-user --pid --fork --mount-proc \
  env PRIME_AGENT_CODING_AGENT_DIR="$SANDBOX" \
  npm --prefix packages/coding-agent run test:ci

Measured just now against a live daemon on pid 681507: kill -0 681507 succeeds on the host and returns No such process inside the namespace. No root, no container runtime — unshare --user is unprivileged where kernel.unprivileged_userns_clone=1. --mount-proc is load-bearing; without it /proc still shows host PIDs.

This is defence in depth, not an alternative to sanitizing the spawn env: your fix makes the spawned daemon boot in the right mode, the namespace bounds the blast radius if any future test spawns something that signals broadly.

2. The second hazard is agent-dir writes, not just process reach. The suite never overrides PRIME_AGENT_CODING_AGENT_DIR, so it writes supervisor logs into the caller's live ~/.prime/agent/logs/. Pointing it at a throwaway dir (above) keeps a test run from touching real session state.

On the side observation about both NO_COLOR=1 and FORCE_COLOR=1 being exported: we see that too, and it surfaces beyond tests — it makes Node print the warning into the stderr of every child process, which is noise in any subprocess-capturing tooling, not only in cleanliness assertions. Setting both does seem worth a separate look, independent of whether tests are made insensitive to it.

Happy to contribute the sandbox recipe as a docs note if that would be useful — following CONTRIBUTING.md, not opening anything unsolicited.