-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
fix(windows): improve Claude CLI scan for paths with spaces #1273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(windows): improve Claude CLI scan for paths with spaces #1273
Conversation
Two fixes for issue AndyMik90#1050: 1. Skip extensionless paths from `where claude` results on Windows. These stubs are not directly executable and cause ENOENT errors. Only validate .cmd, .exe, and .bat files. 2. Use `chcp 65001` to set UTF-8 code page before running cmd.exe. This prevents garbled error messages when validating CLI paths that contain spaces or special characters. Fixes AndyMik90#1050 Co-Authored-By: Claude Opus 4.5 <[email protected]>
…here Apply the same fix to windows-paths.ts utility functions: - findWindowsExecutableViaWhere (sync) - findWindowsExecutableViaWhereAsync (async) Previously these functions would fall back to extensionless paths (e.g., `paths[0]`) if no .cmd/.exe/.bat was found first. Now they strictly filter to only return valid Windows executable extensions. Co-Authored-By: Claude Opus 4.5 <[email protected]>
Apply the same chcp 65001 fix from claude-code-handlers.ts to both validateClaude and validateClaudeAsync in cli-tool-manager.ts. This ensures error messages are correctly encoded in UTF-8 on Windows when validating CLI paths through any code path (initial setup, settings panel, sidebar click). Addresses Sentry feedback about inconsistent UTF-8 handling. Co-Authored-By: Claude Opus 4.5 <[email protected]>
The /s flag only strips outer quotes when the command starts with a
quote character. Since we prepend 'chcp 65001 >nul && ', the command
no longer starts with a quote, so the ""path"" pattern would result
in unbalanced quotes.
Use simple double-quote wrapping ("path") which works correctly
when the command doesn't rely on /s quote stripping.
Co-Authored-By: Claude Opus 4.5 <[email protected]>
Signed-off-by: youngmrz <[email protected]>
Changes: - Use proper quoting for paths in shell-escape utility functions - Fix test: prevent infinite timer loop in requestAnimationFrame mock The requestAnimationFrame mock was using setTimeout(callback, 0) which caused vi.runAllTimersAsync() to enter an infinite loop. Changed to return a unique ID without scheduling timers. Co-Authored-By: Claude Opus 4.5 <[email protected]> Signed-off-by: youngmrz <[email protected]>
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (4)
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello @youngmrz, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the robustness of the Claude CLI integration on Windows by addressing issues related to path handling and command execution encoding. Additionally, it resolves a critical testing problem by refining timer mocks in frontend integration tests, ensuring stable and reliable test execution. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces two important fixes. First, it correctly handles Windows paths with spaces when scanning for and executing the Claude CLI. This is achieved by adjusting the command line for cmd.exe and making the path discovery logic more robust by filtering for executable file extensions. Second, it resolves an infinite loop in the terminal copy/paste integration tests by properly mocking requestAnimationFrame and using vitest's fake timers. The changes are well-implemented and improve both the application's stability on Windows and the reliability of the test suite. I have one minor suggestion to improve the robustness of parsing command output on Windows.
| try { | ||
| if (isWindows) { | ||
| const result = await execFileAsync('where', ['claude'], { timeout: 5000 }); | ||
| const paths = result.stdout.trim().split('\n').filter(p => p.trim()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For better robustness, it's recommended to split the output of the where command using a regular expression that handles both Windows (\r\n) and Unix-style (\n) line endings. While the current implementation with split('\n') and trim() in the loop might work in most cases, using split(/\r?\n/) is safer and more explicit. This also makes the code consistent with how where output is parsed in apps/frontend/src/main/utils/windows-paths.ts.
| const paths = result.stdout.trim().split('\n').filter(p => p.trim()); | |
| const paths = result.stdout.trim().split(/\r?\n/).filter(p => p.trim()); |
Signed-off-by: youngmrz <[email protected]>
|
Reinstating original PR #1156 |
Summary
Supersedes #1156 (which had CI issues)
Test plan
🤖 Generated with Claude Code