fix(claude-code-adapter): send the prompt over stdin, not argv; retry temp cleanup - #296
Merged
Merged
Conversation
… temp cleanup Two real, reproducible failures reviewing PRs on Windows tonight, on every single review attempted regardless of file content: 1. `runClaude` built `args = ["-p", prompt]`, passing the whole prompt (system + conversation +, for a file review, the file's content) as one CLI argument. Windows' ~32K total command-line length is exceeded by a real file plus review instructions regardless of the file's own size — even a single small source file failed as `spawn ENAMETOOLONG`. No batching/token-budget config can fix this: it is the argv itself that is too long, independent of how many files or tokens are involved. Fix: `claude -p` (bare, no literal argument) reads its prompt from stdin — verified live. `runLocalCli` gained a `stdin` option (written to the child before closing it, empty otherwise — no behavior change for existing callers that don't pass it) and `runClaude`/`claudeCode` now send the prompt that way instead. 2. `cleanup()`'s `rmSync(tempRoot, ...)` crashed the whole run uncaught with `EBUSY: resource busy or locked` on Windows, on every single invocation observed — a child process's handle on a file under `tempRoot` can linger past `close`, racing the parent's cleanup. `fs.rmSync`'s own `maxRetries`/`retryDelay` options exist for exactly this documented Windows behavior. ## Test plan - Added: `stdin` option writes content to the child before closing it; omitting it still closes stdin empty (unchanged behavior) - Full suite: 222/309 passing after this change vs. 220/307 before — same 86 pre-existing failures either way (Windows path-separator assertions unrelated to this fix, confirmed via `git stash` against this same branch point), plus the 2 new tests above, both passing - Live: re-ran a real PR review that failed with `ENAMETOOLONG` on every attempt before this fix (AgentsKit-io/agentskit-os#6233) — completed with neither `ENAMETOOLONG` nor `EBUSY` after this fix
EmersonBraun
deleted the
fix/windows-argv-length-and-tempdir-cleanup
branch
September 22, 2026 14:18
3 tasks
Merged
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two real, reproducible failures reviewing PRs on Windows tonight, hit on every single review attempted, regardless of file content:
spawn ENAMETOOLONG—runClaudebuiltargs = ["-p", prompt], passing the whole prompt (system + conversation, and for a file review, the file's own content) as one CLI argument. Windows' ~32K total command-line length is exceeded by a real file's content plus review instructions regardless of the file's own size — even a single, unremarkable source file failed this way. No batching or token-budget config can fix this: it's the argv itself that's too long, independent of how many files or tokens are involved.Fix:
claude -p(bare, no literal argument) reads its prompt from stdin instead — verified live.runLocalCligained astdinoption (written to the child before closing it; empty otherwise, so existing callers that don't pass it see no behavior change), andrunClaude/claudeCodenow send the prompt that way.EBUSY: resource busy or locked—cleanup()'srmSync(tempRoot, ...)crashed the whole run uncaught, on every single invocation observed. A spawned child's handle on a file undertempRootcan linger briefly pastcloseon Windows, racing the parent's cleanup rmSync.fs.rmSync's ownmaxRetries/retryDelayoptions exist for exactly this documented behavior.Test plan
npm run typecheckstdinoption writes content to the child before it closes; omitting it still closes stdin empty (no behavior change for existing callers)git stashagainst this same branch point), plus the 2 new tests above, both passingENAMETOOLONGon every attempt before this fix (AgentsKit-io/agentskit-os#6233) — completed with neitherENAMETOOLONGnorEBUSYafter this fixhttps://claude.ai/code/session_0137fexM8CEcWe2N2Y7igkUY