Fix Windows wizard failure by sending prompt via stdin for stream-json mode#302
Conversation
…n mode When using stream-json output mode on Windows, the prompt was being added both as a CLI argument AND sent via stdin, causing the command line to exceed cmd.exe's ~8191 character limit and resulting in immediate exit code 1. Now detects when stream-json is in the args and ensures the prompt is sent only via stdin, avoiding the command line length limit. Fixes RunMaestro#301 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
dmaynor
force-pushed
the
fix/windows-cmd-length-limit-301
branch
from
ce585da to
2d227ed
Compare
There was a problem hiding this comment.
Pull request overview
This PR fixes a Windows-specific bug in wizard mode where the command line exceeded cmd.exe's ~8191 character limit. The fix prevents duplicate prompt handling by detecting when stream-json output mode is used and sending the prompt only via stdin, not as a CLI argument.
Changes:
- Modified
promptViaStdindetection to include cases where args contain 'stream-json' - Added explanatory comments documenting the Windows command line length issue
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Also critical on Windows: when using stream-json output mode, the prompt is sent | ||
| // via stdin (see stream-json stdin write below). Adding it as a CLI arg too would | ||
| // exceed cmd.exe's ~8191 character command line limit, causing immediate exit code 1. | ||
| const argsHaveStreamJson = args.some((arg) => arg.includes('stream-json')); |
There was a problem hiding this comment.
The detection logic using .includes('stream-json') could potentially match unintended patterns. For example, if a hypothetical flag like --no-stream-json or --stream-json-disabled were used, it would incorrectly trigger stdin mode. Consider using a more precise check that matches the specific expected patterns like arg === 'stream-json' after splitting on equals signs, or check for --output-format followed by stream-json, or --input-format followed by stream-json.
| const argsHaveStreamJson = args.some((arg) => arg.includes('stream-json')); | |
| const argsHaveStreamJson = args.some((arg, index) => { | |
| // Match common patterns: | |
| // - bare "stream-json" | |
| // - "--input-format stream-json" / "--output-format stream-json" | |
| // - "--input-format=stream-json" / "--output-format=stream-json" | |
| if (arg === 'stream-json') { | |
| return true; | |
| } | |
| if (arg === '--input-format' || arg === '--output-format') { | |
| return args[index + 1] === 'stream-json'; | |
| } | |
| if (arg.startsWith('--input-format=') || arg.startsWith('--output-format=')) { | |
| const [, value] = arg.split('=', 2); | |
| return value === 'stream-json'; | |
| } | |
| return false; | |
| }); |
| const argsHaveStreamJson = args.some((arg) => arg.includes('stream-json')); | ||
| const promptViaStdin = sendPromptViaStdin || sendPromptViaStdinRaw || argsHaveStreamJson; |
There was a problem hiding this comment.
There is no test coverage for the new behavior where promptViaStdin is set to true when args contain 'stream-json'. While there are tests that verify isStreamJsonMode detection (lines 132-243 in ChildProcessSpawner.test.ts), there should be a test that verifies the prompt is NOT added to the command line arguments when args contain 'stream-json'. This would ensure the Windows command line length fix is properly covered by tests.
|
Thanks for the fix! |
Summary
stream-jsonoutput mode, the prompt is now sent only via stdin (not duplicated as CLI arg)Root Cause
On Windows with
stream-jsonmode, the prompt was being added both as a CLI argument AND sent via stdin. This caused the command line to exceed Windows' limit, resulting in immediate exit code 1.Test Plan
Fixes #301
🤖 Generated with Claude Code