fix: resolve Claude Code integration hanging on Windows

[EchoingVesper]

• Replace invalid command-line flags with correct Claude Code API
• Use stdin for input instead of command-line args to bypass Windows character limits
• Implement proper SDKMessage format expected by Claude Code
• Add WSL.exe execution path for Windows compatibility

Related GitHub Issue

Closes: #5097

Description

This PR fixes the Claude Code integration hanging issue on Windows by correcting the API usage. The original implementation used non-existent command-line flags (-p for messages, --system-prompt) and tried to pass large payloads via command-line arguments, hitting Windows' 8191 character limit.

Key implementation details:

• Correct API usage: Replace invalid flags with proper --print, --input-format stream-json, --output-format stream-json
• stdin approach: Send JSON input via stdin instead of command-line args to bypass Windows character limits
• Proper message format: Use Claude Code's expected SDKMessage format with type, message, and session_id fields
• Windows compatibility: Detect Windows platform and use wsl.exe to execute Claude Code in WSL

The fix maintains backward compatibility with Linux/Mac while enabling Windows users to use Claude Code through WSL.

Test Procedure

Manual Testing Steps:

1. Set up Windows 11 with WSL2 and Claude Code v1.0.35 installed in WSL
2. Configure Roo Code to use Claude Code as the provider
3. Send a chat message in Roo Code
4. Verify the message is processed without hanging (previously would hang indefinitely)

Testing Environment:

• Windows 11 with WSL2 (Ubuntu)
• Claude Code v1.0.35 in WSL
• VS Code with Roo Code extension in development mode
• Verified with both short and long system prompts

Command-line Verification:

The fix was validated by testing the corrected Claude Code command format directly:

wsl.exe -e bash -c 'echo "{\"type\":\"user\",\"message\":{\"role\":\"user\",\"content\":\"Hello\"},\"session_id\":\"test-123\"}" | claude --print --verbose --input-format stream-json --output-format stream-json

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

N/A - This is a backend integration fix with no UI changes.

Documentation Updates

• No documentation updates are required.

The fix maintains the same user interface and configuration. Windows users can now use Claude Code seamlessly without
additional setup steps.

Additional Notes

This fix enables the Claude Code integration to work on Windows as originally intended. The solution is platform-aware and
doesn't affect Linux/Mac functionality. The implementation follows Claude Code's documented SDKMessage format for proper API
communication.

Get in Touch

Discord: echoingvesper

---

Important

Fix Claude Code integration on Windows by correcting API usage, using stdin for input, and ensuring WSL compatibility in run.ts.

• Behavior:
  • Replace invalid command-line flags with --print, --input-format stream-json, --output-format stream-json in runProcess().
  • Use stdin for JSON input to bypass Windows character limits in runProcess().
  • Implement SDKMessage format with type, message, and session_id fields in runProcess().
  • Detect Windows platform and use wsl.exe for execution in runProcess().
• Refactoring:
  • Rename process to childProcess in runClaudeCode() and runProcess().
• Misc:
  • Update run.ts to handle Windows compatibility while maintaining Linux/Mac functionality.

^{This description was created by for 3d667cf08b9c4c54d3f4ddba94c2bac96f200cc5. You can customize this summary. It will automatically update as commits are pushed.}

[EchoingVesper]

Thank you for the thorough review! You're absolutely right about the prompt restructuring being unnecessary for the Windows fix.

I've updated the PR to include only the minimal changes needed:

1. ✅ Using stdin instead of command-line arguments for input
2. ✅ Fixed command-line flags (--print, --input-format stream-json)
3. ✅ Added WSL execution wrapper for Windows

All prompt formatting/restructuring has been removed. The changes are now focused solely on fixing the Windows compatibility issue as you suggested.

The PR now contains just one file change with +53/-17 lines in src/integrations/claude-code/run.ts.

[EchoingVesper]

Update: After testing the minimal approach, I discovered that some form of message transformation is actually necessary for Claude Code compatibility.

Claude Code expects input in its SDKMessage format, where the message content needs to be properly formatted. Without this transformation, the connection succeeds but Claude Code cannot process the messages correctly.

The current fix includes:

1. ✅ Using stdin instead of command-line arguments
2. ✅ Fixed command-line flags (--print, --input-format stream-json)
3. ✅ WSL execution wrapper for Windows
4. ✅ Minimal message formatting to match Claude Code's expected input format

The message transformation is kept as minimal as possible - just wrapping the input in the required SDKMessage structure that Claude Code expects.

[wehrmannit]

@EchoingVesper I noticed that my wsl responds with a title change command in front of the correct output for some reason.

ERR [Extension Host] Error parsing chunk: SyntaxError: Unexpected token '�', "�]0;claude"... is not valid JSON

The correct JSON is right after that.

I don't know if it's just me but I felt like I should mention it.

[EchoingVesper]

@EchoingVesper I noticed that my wsl responds with a title change command in front of the correct output for some reason.

ERR [Extension Host] Error parsing chunk: SyntaxError: Unexpected token '�', "�]0;claude"... is not valid JSON

The correct JSON is right after that.

I don't know if it's just me but I felt like I should mention it.

I didn't run into that in my testing on my system, so I'm not sure, and I tested for a while last night on something else.

I did notice, however, that it passes the entire system prompt and all mode prompts on every message, which burns through tokens like nothing else, and the AI responds as if it's a new chat on each message. I also noticed that sometimes portions of the context seem to be lost. I'm not sure how to fix these issues.

Those weren't, however the actual bug I was trying to fix and I don't have time or energy to mess with it more today. I also notice there's another PR trying to fix Claude Code on Windows, so I'm unsure if this one is even necessary any longer.

[SannidhyaSah]

I've reviewed this PR and while I understand the hanging issue on Windows is real, I have some concerns about the implementation approach:

Critical Issues:

1. Conflicting Information: The PR description mentions that -p and --system-prompt flags are invalid, but the official Claude Code CLI documentation shows claude -p "query" as a documented command. Could you clarify what specific issue you encountered with these flags?

2. Security Vulnerability: The code uses Math.random() for session ID generation, which is cryptographically insecure. Consider using crypto.randomUUID() or crypto.getRandomValues() instead.

3. Missing Test Coverage: This critical integration functionality lacks any test coverage, making it difficult to verify the proposed changes work correctly across different platforms.

Implementation Concerns:

4. Complex Platform Logic: The WSL detection and execution adds significant complexity. Have you tested this approach with different Windows configurations and Claude Code installations?

5. Error Handling: The stdin-based approach introduces new failure modes that aren't handled - what happens if the stdin write fails or the process doesn't read the expected format?

6. Backwards Compatibility: This completely changes how Claude Code is invoked. Are there any compatibility concerns with different Claude Code versions?

Questions for Clarification:

• What specific error messages or behavior did you see with the original -p flag approach on Windows?
• Has this WSL-based solution been tested with actual Claude Code installations?
• Could you provide more details about the character limit issue that necessitated this change?

The hanging issue definitely needs to be addressed, but it would be helpful to understand the specific failure mode better to ensure this solution is the right approach.

[daniel-lxs]

Thank you for your contribution @EchoingVesper, we really appreciate it.

While there's nothing wrong with the changes here, I believe the issue this PR was addressing has already been resolved by #5186.

I'll go ahead and close this one for now, but feel free to reach out if you have any questions. Looking forward to seeing more contributions from you!