crashlabs/huskies
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 26 Wiki Activity

storkit: create 452_bug_claude_code_pty_crashes_with_fatal_runtime_error_on_agent_restart

Browse Source
This commit is contained in:
dave
2026-03-31 11:25:59 +00:00
parent ac84e7240e
commit fecb157291
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.storkit/work/1_backlog/452_bug_claude_code_pty_crashes_with_fatal_runtime_error_on_agent_restart.md
+5 -5
View File
@@ -8,14 +8,14 @@ name: "Claude Code PTY crashes with fatal runtime error on agent restart"
When agent processes (Claude Code PTY sessions) exit, storkit does not reap the child processes, leaving them as zombies (`[claude] <defunct>`). These accumulate over time — observed 101 zombie processes in one session. When the zombie count gets high enough, new PTY allocations fail and Claude Code crashes immediately on startup with `fatal runtime error: assertion failed: output.write(&bytes).is_ok(), aborting`. The process exits in the same second it spawns (Session: None), burns through retries, and blocks the story.
Root cause: storkit runs as PID 1 inside Docker. As PID 1, it is responsible for reaping all orphaned child processes. The zombies are mostly grandchildren (`esbuild`, `echo`, `sh`, `cargo`) spawned by `npm run build`, `cargo test`, etc. during worktree setup and gate checks. When these grandchild processes exit, they get reparented to PID 1 (storkit), which never calls `waitpid(-1, WNOHANG)` to reap them.
Root cause: storkit does not reap orphaned grandchild processes. The zombies are mostly grandchildren (`esbuild`, `echo`, `sh`, `cargo`) spawned by `npm run build`, `cargo test`, etc. during worktree setup and gate checks. This happens both natively (observed 27 zombies on macOS host) and in Docker containers. When the intermediate parent exits, these grandchildren get reparented to storkit (or PID 1 in Docker) and become zombies because nobody calls `waitpid` for them.
Additionally, `llm/providers/claude_code.rs` has two code paths that call `child.kill()` without a following `child.wait()` (the cancel path at line 286 and the timeout kill at line 367), leaving direct-child zombies. `agents/pty.rs` correctly calls `child.wait()` after `child.kill()`.
The fix is one or both of:
1. Add a background reaper thread/task in storkit that periodically calls `waitpid(-1, WNOHANG)` to clean up orphaned processes
2. Use `tini` or `dumb-init` as the Docker entrypoint to handle PID 1 reaping responsibilities
3. Add missing `child.wait()` calls after `child.kill()` in `claude_code.rs`
The fix should include:
1. Add a background reaper thread/task in storkit that periodically calls `waitpid(-1, WNOHANG)` to clean up orphaned processes (handles both native and Docker)
2. Add missing `child.wait()` calls after `child.kill()` in `claude_code.rs`
3. Optionally use `tini` or `dumb-init` as the Docker entrypoint as a belt-and-suspenders measure
## How to Reproduce