fix(agent): honor RuntimeProcessOptions.stdin in the container runtime (PRI-3250)

[ada-sen]

Based on main. The stdin option this builds on landed in #418 (PRI-3243); the process-group kill work is deferred to #413 and is not part of this PR.

Problem

#418 gave RuntimeProcessOptions a stdin?: 'ignore' | 'pipe' option, defaulted to 'ignore', so a bash spawn doesn't hang on a command that unexpectedly reads stdin (e.g. head with no file args). That only reaches the host runtime (HostProcessRunner.start() in host.ts); types.ts said so explicitly.

The container runtime's ProjectedContainerProcessRunner.start() (packages/agent/src/tools/runtime/projected-container.ts) never read opts.stdin. It always calls containerManager.execStream(), which spawns its docker/container/plane CLI with -i and a piped stdin (see execStream() in docker-container.ts, apple-container.ts, plane-runtime.ts). Nothing wrote to or closed that pipe, so a container-run command that fell back to reading stdin would hang forever. Same shape as PRI-3243, one layer down. This is PRI-3250.

Fix

• ProjectedContainerProcessRunner.start() ends the execStream handle's stdin immediately (with an error listener to swallow EPIPE) unless the caller passed stdin: 'pipe'. The returned RuntimeProcessHandle.stdin is undefined in that case, so a caller can't write to an ended stream.
• Every container-mode caller that writes stdin now opts in:
  • container-exec-fs.ts writeTextFile passes stdin: 'pipe', and kills the process and throws if the pipe is still missing.
  • container-exec-network.ts fetch passes stdin: 'pipe' only when there is a body, and kills curl and throws if the pipe is missing, instead of silently sending an empty body.
• Callers audited and unaffected: bash.ts and shell-job.ts pass stdin: 'ignore'; runtime-stdio-transport.ts (in-container MCP servers) already passes stdin: 'pipe'; stat/readTextFile/mkdir/readdir, file_find.ts and ripgrep_search.ts use exec() and never write stdin.
• types.ts: the RuntimeProcessOptions.stdin doc now says every runtime honors it.

Tests

• projected-container.test.ts
  • ends the container stdin pipe immediately when the caller does not opt into it: end() called once, stream writableEnded, returned handle.stdin undefined. Fails against the pre-fix runner.
  • does not end the container stdin pipe when the caller opts into stdin: pipe: guards against ending or hiding the pipe for 'pipe' callers, including writing through the returned handle. A runner that ignored opts.stdin would also pass this one; the test above is what requires 'ignore' to be honored.
  • container stdin writers composed with the real runner: the real ProjectedContainerProcessRunner wired to the real ContainerExecFileSystem / ContainerExecNetworkClient. writeTextFile content and a POST body both arrive over the container stdin pipe. Both fail if either call site drops stdin: 'pipe'.
• container-exec-fs.test.ts / container-exec-network.test.ts: the fakes hand back a live stdin only for stdin: 'pipe', like the real runners. They can also withhold stdin and count kill() calls, and new tests cover the fail-loud branches: writeTextFile and a body-bearing fetch each kill the process and throw ... write stream unavailable, and a body-less fetch works without stdin. Reverting either guard to a silent skip fails its test.

This round

• Restacked onto current main without any fix(agent): reap detached bash process groups within the parent's kill window (PRI-3243) #413 commits; the stdin option now comes from fix(agent): bash tool spawns no longer hang on an inherited stdin (PRI-3243) #418. Resolved the one conflict, the container-exec-network.test.ts type import (RuntimeProcessRunner, RuntimeProcessHandle, RuntimeProcessOptions, ToolRuntime).
• Added the fail-loud branch tests above.
• Rewrote the 'pipe' opt-in test's comment to say what it actually guards.
• Stripped review-history narration and commit SHAs from code and test comments, and renamed the composed-test describe block.
• Updated the types.ts doc comment.

Gates on the pushed head: npm run build, npm run lint, npm run format:check, npm run typecheck, and npm run test --workspace=packages/agent (3833 passed, 27 skipped; 283 passed, 12 skipped in the serial e2e pass).

[obra]

Review from jc: competing adversarial reviewers, then a verifier that tried to refute every finding against the PR head and current origin/main. Verdict: changes-needed.

The underlying gap still exists on origin/main: projected-container.ts:428 still returns containerHandle.stdin unconditionally, and #413 is still open, so the fix is still needed. As committed, though, it breaks every container file_write/file_edit and silently empties url_fetch POST bodies, because the only two production stdin writers (container-exec-fs.ts:82 and container-exec-network.ts:49) never pass stdin:'pipe'. The #413 review flagged exactly this, and the PR body wrongly claims those paths are unaffected. The fix is small: add stdin:'pipe' at both call sites, add composed tests, and correct the body. It merges cleanly onto origin/main.

Confirmed findings:

1. [critical, fix: small] packages/agent/src/tools/runtime/projected-container.ts:402-408,446 with container-exec-fs.ts:82-86
   All container-mode file writes break. ContainerExecFileSystem.writeTextFile calls this.process.start(['sh','-c','base64 -d > "$0"', p]) without stdin:'pipe'. The runner now ends the pipe and returns stdin: undefined, so writeTextFile throws 'ContainerExecFileSystem write stream unavailable'. That breaks file_write and file_edit for every projected-container runtime. The fix(agent): reap detached bash process groups within the parent's kill window (PRI-3243) #413 review warned about exactly this call site.
   Why it's real: I checked the PR head (21eb956). projected-container.ts:516 wires this.fs = new ContainerExecFileSystem(this.process), where this.process is the modified ProjectedContainerProcessRunner. container-exec-fs.ts:82 passes no opts, so opts.stdin defaults to 'ignore'. :446 then returns stdin undefined and :83-85 throws. Two reviewers independently reproduced it through the real runtime and saw it pass with the fix reverted.
   Suggested fix: Pass { stdin: 'pipe' } to the start() call in writeTextFile. Add a test that composes ProjectedContainerToolRuntime (fake execStream manager) with runtime.fs.writeTextFile, so the fs layer is exercised through the real runner.
2. [critical, fix: small] packages/agent/src/tools/runtime/projected-container.ts:402-408,446 with container-exec-network.ts:49-56 (origin/main :119-125)
   Container-mode POST bodies are silently dropped. ContainerExecNetworkClient.fetch starts curl with --data-binary @- and no stdin:'pipe'. handle.stdin is now undefined, so the if (handle.stdin) guard skips the body write. curl reads EOF and sends an empty body, and no error is raised.
   Why it's real: projected-container.ts:517 wires this.network = new ContainerExecNetworkClient(this.process). container-exec-network.ts:49 calls start(argv, { signal }) with no stdin option. On origin/main the start call and guard are unchanged, and git merge-tree against origin/main is clean, so the regression survives a rebase. Both reviewers reproduced '' being written in place of the body.
   Suggested fix: Pass { signal: opts?.signal, stdin: 'pipe' } in fetch. Consider replacing the silent if (handle.stdin) skip with a throw when hasBody is set and stdin is missing, as writeTextFile does. Add a composed runtime.network.fetch POST test.
3. [important, fix: trivial] PR #415 body paragraph 3 / commit 21eb956cb message
   The PR body falsely says ContainerExecFileSystem/ContainerExecNetworkClient have their 'own low-level exec-with-stdin paths ... unaffected by this change'. Both go through the exact ProjectedContainerProcessRunner.start() this PR changes.
   Why it's real: The only production construction of both classes is projected-container.ts:516-517 over this.process. Neither has a separate exec path. Both call this.process.start().
   Suggested fix: After adding stdin:'pipe' at both call sites, correct the body to list every stdin writer and say how each is handled.
4. [important, fix: small] packages/agent/src/tools/runtime/__tests__/container-exec-fs.test.ts:29 and container-exec-network.test.ts fake runners; projected-container.test.ts:651-697
   No test composes the real container runner with its stdin-writing consumers, so CI stays green while container writes and POSTs are broken. The fs/network suites use fake runners whose start() ignores opts and always returns a stdin. The new tests call only runtime.process.start directly.
   Why it's real: The fake start(command) signature has no opts parameter, so it cannot observe the stdin option. Both reviewers ran the relevant suites on the PR head, and they all passed while the composed repros failed.
   Suggested fix: Make the fake runners honor opts.stdin (return stdin only for 'pipe'), or add composed ProjectedContainerToolRuntime tests for fs.writeTextFile and network.fetch with a body. Either one would have failed on this PR.

Refuted by the verifier: The 'does not end the container stdin pipe when the caller opts into stdin: pipe' test is vacuous (minor); Duplicate findings from Reviewers A and B (items 1-4 each)

https://claude.ai/code/session_01PvaV8ypCvokp6DCcW6rT7f

[ada-sen]

Addressed in 261ba21:

1/2. writeTextFile / fetch never passed stdin: 'pipe': both now do (fetch only when there's a body). Also made both fail loudly — fetch now throws if hasBody but handle.stdin is missing, matching writeTextFile's existing throw, instead of silently sending an empty body.
3. PR body's false "unaffected" claim: corrected — added a full audit of every RuntimeProcessRunner.start()/exec() caller in container mode (bash.ts, shell-job.ts, runtime-stdio-transport.ts are all fine; container-exec-fs.ts/container-exec-network.ts were the two broken ones; the exec()-only callers in container-exec-fs.ts/file_find.ts/ripgrep_search.ts never write to stdin either way) to the PR description.
4. Test gap — fakes don't observe opts: updated both container-exec-fs.test.ts's and container-exec-network.test.ts's fake runners to honor opts.stdin (live stdin only for 'pipe'), and added composed tests in projected-container.test.ts that wire the real ProjectedContainerProcessRunner to the real ContainerExecFileSystem/ContainerExecNetworkClient — the actual production integration seam. Confirmed both fail on d449f51 (writeTextFile throws "write stream unavailable"; the POST body test observes an empty write with no error) and pass on 261ba21.
5 (minor, refuted). Also strengthened the "does not end the container stdin pipe when the caller opts into stdin: pipe" test your verifier flagged as vacuous — it now writes through the returned handle and confirms the bytes actually arrive on the container-side pipe, not just reference-equality/not-called assertions that were equally true pre-fix.