Establish how Secant can contain a Harness's descendant processes on Windows

[Sandstorm831]

Question

On Windows, which of a Harness's descendant processes escape Secant's taskkill /T /F and Claude Code's own tool stop, and what can contain them? Establish:

• which Bash-tool commands escape the tree (a script run through Git Bash did, with a dead parent pid);
• whether a Windows Job Object with kill-on-close, assigned at spawn, reaches them, and how Bun can create one (built-ins, bun:ffi, or a dependency);
• whether Codex's turn/interrupt stops a running shell command's tree on Windows;
• what T3 Code, OpenCode, and the native Claude Code and Codex clients do on Windows.

[Sandstorm831]

Starting context

Input	Why it matters	Authority
The Windows live recording in docs/research/windows-live-interrupt-and-steer.md, on branch research/255-windows-live (merged through PR #257)	A script run through Git Bash has a dead parent pid and survives both Claude Code's taskkill /PID <bash> /T /F and Secant's taskkill /T /F, and it ran to completion after the Interrupt and after the process exited. A PowerShell tool tree and a direct native command were killed. Its Still Unknown list names the open cases.	Research
ADR 0035, paragraph "How Claude Code stops"	Records the Windows limit and hands containment to Decide how Secant contains a Harness's descendant processes on Windows	Canonical decision
src/process/process.ts (the Windows taskkill /T /F path and escalated), src/process/AGENTS.md	Where Secant stops process trees today; the Process Interface any containment lands behind	Canonical (current behaviour)
docs/agents/dependencies.md	The built-ins-first rule that any Job Object route (bun:ffi or a package) must pass	Canonical
T3 Code (local clone) and OpenCode (local clone), per the map's Guides note	Default authority for how others handle Harness process trees on Windows	Guide

Reading rule

Start from the recording's Git Bash finding and its Still Unknown list. Establish which commands escape and why, then whether a Job Object with kill-on-close assigned at spawn contains them under Bun, and how. Check Codex's turn/interrupt on a running shell command. Report facts only; the choice belongs to the decision ticket. The findings land under docs/research/ on a research/<name> branch.

[Sandstorm831]

Resolution

Git Bash programs escape taskkill /T /F on Windows, and a Job Object that allows no breakaway contains them. Bun can create one only
through bun:ffi. Codex's turn/interrupt leaves a running command alive.

• What escapes. A command escapes when Git Bash forks and the fork then runs another MSYS program. The fork exits once the exec succeeds,
  so the new program's Windows parent is dead and taskkill /T can't follow the link. Escaped: ./x.sh, bash x.sh, sh x.sh, bash -c '…',
  a bare sleep, and everything they start. Killed: native commands (ping, bun, powershell, cmd), pipelines and subshells of them,
  cmd & wait, and exec ./x.sh. Each case ran once.
• Job Object. A job with KILL_ON_JOB_CLOSE and no breakaway limit, assigned right after spawn, held every escaped process. Closing it or
  TerminateJobObject killed all 15 cases. With a live Claude Code, TerminateJobObject on a job around claude.exe killed the tool shells and
  the dead-parent script (2 of 2). If the job has BREAKAWAY_OK or SILENT_BREAKAWAY_OK, the MSYS runtime spawns with
  CREATE_BREAKAWAY_FROM_JOB and the Git Bash processes survive.
• Bun.
  • Its spawn has no job or suspended-spawn option.
  • Its libuv already puts each non-detached child in a global job that allows breakaway, so that job kills only the direct child.
  • bun:ffi against kernel32 works, including in a bun build --compile binary, and the job nests under libuv's. Bun documents bun:ffi as
    experimental.
  • Assign-after-spawn leaves a gap of 0.04–0.16 ms. Closing it needs CREATE_SUSPENDED or PROC_THREAD_ATTRIBUTE_JOB_LIST, which Bun's spawn
    can't reach.
  • Against the dependencies rule: bun:ffi is a built-in already allowlisted only for conhost-notice.ts. No general npm Job Object package
    was found, and koffi would be a native dependency.
• Codex. turn/interrupt ended the Turn interrupted, but the command tree kept running while the app-server lived (5 of 5). The process
  is kept as a background terminal. thread/backgroundTerminals/clean (experimental) or app-server exit ends Codex's per-command job, which
  allows breakaway, so a Git Bash script run without a PTY outlived both (2 of 2). A Secant-style job around codex.exe killed it (1 run). The
  runs used approvalPolicy: never and danger-full-access, so the Windows-sandbox path is untested.
• Others.
  • Claude Code uses taskkill /PID <pid> /T /F and no job of its own (read from binary strings and a probe).
  • OpenCode and T3 Code use taskkill and no Job Objects.
  • Codex uses jobs that allow breakaway: attached at creation for a PTY, assigned after spawn for pipes.
• Untested or Unknown:
  • Codex's sandboxed path.
  • Whether Codex's PTY kill comes from the job or from the console closing.
  • The job chain above the agent shell.
  • The real assign gap for claude.exe and codex.exe.
  • Whether an ffi CreateProcessW spawn can keep Bun-managed stdio.
  • Uncaptured Git Bash cases (xargs, find -exec, make, npm scripts).
  • Other Claude Code versions or bashes.
  • A Claude Code string suggesting the tool kill is skipped on an "interrupt" abort.
  • What a job does to processes a Harness detaches on purpose (background Bash tasks, MCP servers, Codex background terminals).

Findings: docs/research/windows-process-containment.md on branch research/258-windows-containment.

[Sandstorm831]

Resolution addendum

The first pass left several items Untested that this machine could test. A follow-up ran each of them live on Windows 11, with Claude Code 2.1.283 and codex-cli 0.155.0, and updated the same research note. The answers below replace the "Untested or Unknown" list above.

• Codex's Windows sandbox, with Secant's real settings. Approval and sandbox are left unset, so the user's config gives on-request and workspaceWrite.
  • Git Bash cannot run in the sandbox at all: MSYS aborts with "couldn't create signal pipe", so the fork-and-exec escape never arises there.
  • A sandboxed native command runs under a restricted token, in Codex's per-command job that allows breakaway. turn/interrupt leaves it running (3 of 3), while the clean request or app-server exit stops it (3 of 3).
  • An outer Secant job that allows no breakaway still contains it, and killing that job ends the whole tree (3 of 3).
• Codex PTY mode. The kill comes from the pseudoconsole closing when pwsh dies, not from Codex's job. The escaped script is not a member of that job.
• The job chain. Breakaway climbs out of the libuv and Harness jobs until a job that allows no breakaway stops it. Under a Secant job, every tool descendant is a member.
• Assign-after-spawn gap. Assigning after spawn took 56–224 µs. In 0 of 20 launches of each Harness was any real descendant created before the assignment.
• More Git Bash cases. xargs, find -exec, npm run, npx, bun run, | tee, &, nohup and disown all escape taskkill /T /F, and a no-breakaway job contains every one (3 runs each). CLAUDE_CODE_GIT_BASH_PATH pointed at usr\bin\bash.exe doesn't change the escape.
• Claude Code's interrupt. A raw interrupt still runs taskkill /PID <tool shell> /T /F (3 of 3). The "skip on interrupt" string in the binary is a different kill.
• What a job does to processes a Harness detaches on purpose.
  • A no-breakaway job kills Claude Code's run_in_background Bash when it closes (2 of 2).
  • Inside such a job, CREATE_BREAKAWAY_FROM_JOB fails with ERROR_ACCESS_DENIED (5). Codex already puts each stdio MCP server in a no-breakaway job of its own, where this failure occurs, and it falls back to starting the server uncontained.
• Codex's stall after stdin closed. The escaped script inherits the command's pipe, and the app-server waits for that pipe's EOF.
• A contained spawn that keeps streamed stdio. bun:ffi CreateProcessW with PROC_THREAD_ATTRIBUTE_JOB_LIST puts the child in the job at creation. The prototype uses PROC_THREAD_ATTRIBUTE_HANDLE_LIST to limit inheritance to the child's three stdio handles.
  • Each stdio stream is a node:net named-pipe server, whose client end the child inherits, so Secant keeps async net.Socket streams. Wrapping anonymous pipes as C-runtime fds fails (EBADF).
  • Live Claude Code over stream-json and Codex over app-server were contained 3 of 3 each. So was a parent crash, and 64 MiB moved in 70–86 ms.
  • Not covered: argv quoting and PATH lookup, .cmd shims, a custom env block, and a non-polling exit wait.

Still Unknown:

• The contained spawn run from a bun build --compile binary or through a .cmd shim.
• Other Claude Code releases, or a non-MSYS bash (only 2.1.283 is installed, and WSL is not).
• A job-free baseline: the host process is itself in a job, so the runs compare named jobs instead.

Findings: docs/research/windows-process-containment.md on branch research/258-windows-containment-followup.

[Sandstorm831]

Preserved contained-spawn prototype

The human requested a GitHub branch so this Windows experiment is accessible from their Ubuntu setup and future implementation sessions. The source is now preserved on prototype/issue-259-windows-contained-spawn, kept separate from main with no merge or PR planned.

• Exact prototype snapshot
• README: question, evidence, prerequisites, reproduction, and adoption limits
• At-creation contained-spawn call sequence
• Retained prototype branch

The five TypeScript sources were preserved byte-for-byte, checked against the original Temp files, and verified against their committed Git blobs. Source checksums are included; session logs and generated output are excluded. The original source's echo driver was re-run successfully on Windows with Bun 1.4.2: child in the job, stdin/stdout/stderr round trip, and expected child exit code 7. This does not add compiled-binary or production qualification.

On Ubuntu, retrieve and inspect it with:

git fetch origin prototype/issue-259-windows-contained-spawn
git show FETCH_HEAD:prototypes/windows-contained-spawn/stdio/contained-spawn.ts

Execution remains Windows-specific. The README identifies the drivers' original hard-coded scratch paths and the remaining production obligations. Retain this branch until the selected contained-spawn implementation is built and verified; deliberate adoption belongs in the Process Module under the engineering baseline.

Carry this commit-pinned input forward when preparing the implementation spec and ticket Starting context for Decide how Secant contains a Harness's descendant processes on Windows.

Archive CI: the amended commit 429f065b0c8c986cc78dff2d362491fa503752fd passed the Check workflow. The archive now has narrowly scoped formatter/linter exclusions for the unchanged experimental sources and a formatted README; its recorded source checksums remain intact.

Retained local experiment location

In the Windows checkout, the retained local experiment is at .agent/prototypes/secant258exp/; its PRESERVATION.md records the retention decision. This is the backup copy itself, not a second separate experiment directory. The former %TEMP%/secant258exp copy was removed as a verified duplicate during cleanup.

The published prototype branch remains the shared reference accessible from Ubuntu. The repo-relative path above identifies the separately retained local experiment copy without publishing an absolute machine path.