fix(windows): resolve Claude CLI detection race condition on GUI launch

[VDT-91]

Summary

• Fixes race condition where version check runs before settings load, causing Claude CLI to show "not found" initially
• Suppresses expected "node is not recognized" error on Windows with nvm-windows + GUI launch
• Claude CLI now detects correctly immediately on startup without requiring manual refresh

Problem

When Auto Claude starts from Windows GUI (Start Menu, desktop shortcut) - not terminal:

1. Race condition: CLAUDE_CODE_CHECK_VERSION IPC called before user settings load, so getToolInfo('claude') did fresh detection ignoring user config
2. npm.cmd failure: With nvm-windows, node isn't in PATH when launched from GUI, causing npm.cmd config get prefix to fail with "node is not recognized"

Solution

Change 1: Make getToolInfo() respect user configuration

• Added getUserConfiguredPath() helper to extract user-configured paths
• Added validateToolByType() helper to validate paths by tool type
• Updated getToolInfo() to check user config FIRST before fresh detection

Change 2: Suppress expected Windows error

• Added check in getNpmGlobalPrefixAsync() to detect expected "is not recognized" error on Windows
• Only logs error if it's NOT the expected nvm-windows issue

Files Changed

File	Change
apps/frontend/src/main/cli-tool-manager.ts	Added helpers, updated getToolInfo()
apps/frontend/src/main/env-utils.ts	Suppressed expected Windows error

Test Plan

• Verified fix works with npm start from terminal
• Test Windows GUI launch (Start Menu/desktop shortcut)
• Verify no regression on macOS/Linux

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Much improved Claude CLI detection on Windows: broader install sources supported (official installer, npm, local bin, Scoop, Chocolatey, Program Files, nvm-windows) and refined detection order.
  • Added Windows Registry PATH discovery (sync + async) with PATH parsing and env-var expansion.
  • Enhanced environment/path augmentation and command spawning for better Windows compatibility.

• Tests

  • Updated test scaffolding to mock Windows registry and env-var behaviors for reliable Windows-related tests.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[xytras1]

Workaround confirmed on Windows:

Adding Claude CLI path (C:\Users\<user>\.local\bin) to System PATH did not resolve the "Claude CLI not found" error.

However, launching Auto-Claude from a terminal where claude --version works does work:

# Git Bash / MINGW
"/c/Users/<user>/AppData/Local/Programs/auto-claude-ui/Auto-Claude.exe"

# Or CMD/PowerShell
"C:\Users\<user>\AppData\Local\Programs\auto-claude-ui\Auto-Claude.exe"

This suggests the Electron app isn't inheriting the system PATH properly on startup, but does inherit the terminal's environment when launched from command line.

[VDT-91]

Follow-up Fix: Windows Registry PATH Detection

Thanks for the feedback @xytras1! Your report helped identify the root cause.

The Problem

Windows Electron GUI apps don't inherit the full PATH from the user's shell environment. When you add Claude CLI to your Windows PATH via System Settings, process.env.PATH in the Electron app may not reflect this change until the system is restarted or Explorer.exe is restarted.

This is why launching from terminal worked (terminal has correct PATH) but launching from Start Menu/Desktop didn't.

The Fix

We now read the TRUE Windows PATH directly from the Windows Registry:

• HKEY_CURRENT_USER\Environment\Path (User PATH)
• HKEY_LOCAL_MACHINE\SYSTEM\...\Environment\Path (System PATH)

This bypasses the PATH inheritance issue entirely.

New Windows Detection Order

1. Registry PATH (HKCU + HKLM)     ← NEW: TRUE Windows PATH
2. Known paths (~\.local\bin, npm, Scoop, Chocolatey)
3. nvm-windows paths               ← NEW: Support for nvm-windows
4. Augmented process.env.PATH      (fallback)
5. where.exe                       (last resort)
6. User config                     (manual override)

macOS/Linux detection unchanged.

Testing

• Added 37 new tests (61 total, all passing)
• Covers Registry parsing, env var expansion, nvm-windows, detection order
• Cross-platform safety verified (macOS/Linux tests still pass)

Edge Cases Handled

• ✅ Environment variables in Registry (%USERPROFILE%\.local\bin)
• ✅ reg.exe blocked by Group Policy (falls back to known paths)
• ✅ Custom NVM_HOME for nvm-windows users
• ✅ Multiple install methods (official installer, npm, Scoop, Chocolatey)

---

@xytras1 - Can you test this fix when it's merged? The Claude CLI should now be detected even when launched from Start Menu/Desktop.

[coderabbitai]

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/frontend/src/main/__tests__/cli-tool-manager.test.ts (1)

273-286: Bug: pathStr is referenced but not defined in the callback scope.

The existsSync mock implementation references pathStr which is not defined within that function. This will cause a ReferenceError at runtime.

🐛 Proposed fix

     it('should handle NVM directory with no version subdirectories', () => {
       vi.mocked(os.homedir).mockReturnValue(mockHomeDir);

       vi.mocked(existsSync).mockImplementation((filePath) => {
-        return String(filePath).includes('.nvm') && pathStr.includes('versions') && pathStr.includes('node');
+        const pathStr = String(filePath);
+        return pathStr.includes('.nvm') && pathStr.includes('versions') && pathStr.includes('node');
       });

       // Empty NVM directory
       vi.mocked(readdirSync).mockReturnValue([]);

       const result = getToolInfo('claude');

       expect(result.source).not.toBe('nvm');
     });

🤖 Fix all issues with AI agents

In @apps/frontend/src/main/cli-tool-manager.ts:
- Around line 352-407: The current getWindowsRegistryPath uses blocking
execFileSync which can stall the main thread; add an async counterpart
getWindowsRegistryPathAsync that mirrors getWindowsRegistryPath but uses an
async execFile (e.g., child_process.promises.execFile or promisified execFile)
with the same args, timeouts and reuses parseRegOutput for parsing, returning
Promise<string | null>; then update detectClaudeAsync to call
getWindowsRegistryPathAsync instead of the sync findClaudeInRegistryPath/path
usage (and refactor or remove findClaudeInRegistryPath if redundant) so all
registry reads in async flows are non-blocking.
- Around line 1534-1612: The async Windows detection path calls the synchronous
registry helper findClaudeInRegistryPath(), which uses execFileSync and blocks
the event loop; create an async variant (e.g., findClaudeInRegistryPathAsync)
that uses child_process.execFile (or promisified execFile) and returns a
Promise<string|undefined>, import/use that in detectClaudeAsync (replace the
call at the top of the Windows branch with await
findClaudeInRegistryPathAsync()), and ensure any related helpers/exports and
callers are updated (and remove or keep the sync version only for sync detection
code) so validateClaudeAsync is awaited against the async registry result.
- Line 428: The extensions array includes an empty string which contradicts the
JSDoc and can match names without extensions; remove the '' entry from the const
extensions = ['.exe', '.cmd', '.bat'] and update the surrounding JSDoc to state
explicitly that the function only checks .exe, .cmd, and .bat extensions (adjust
any callers expecting a bare filename if necessary).

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2a45e07 and aee3a63.

📒 Files selected for processing (2)

• apps/frontend/src/main/__tests__/cli-tool-manager.test.ts
• apps/frontend/src/main/cli-tool-manager.ts

🧰 Additional context used

📓 Path-based instructions (3)

apps/frontend/src/**/*.{ts,tsx,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings

Files:

• apps/frontend/src/main/__tests__/cli-tool-manager.test.ts
• apps/frontend/src/main/cli-tool-manager.ts

apps/frontend/src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Use useTranslation() hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components

Files:

• apps/frontend/src/main/__tests__/cli-tool-manager.test.ts
• apps/frontend/src/main/cli-tool-manager.ts

apps/frontend/**/*.{ts,tsx}

⚙️ CodeRabbit configuration file

apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.

Files:

• apps/frontend/src/main/__tests__/cli-tool-manager.test.ts
• apps/frontend/src/main/cli-tool-manager.ts

🧠 Learnings (1)

📓 Common learnings

Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:48.743Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings that should be localized) can be deferred to future i18n cleanup passes rather than requiring immediate fixes in PRs that don't introduce new i18n violations.

🧬 Code graph analysis (1)

apps/frontend/src/main/__tests__/cli-tool-manager.test.ts (1)

apps/frontend/src/main/cli-tool-manager.ts (8)

• getClaudeDetectionPaths (164-202)
• parseRegOutput (297-310)
• expandWindowsEnvVars (326-337)
• getWindowsRegistryPath (352-407)
• findClaudeInRegistryPath (417-443)
• getNvmWindowsPaths (462-498)
• getToolInfo (2147-2165)
• getToolInfo (2239-2241)

🔇 Additional comments (17)

apps/frontend/src/main/cli-tool-manager.ts (8)

172-193: Good expansion of Windows platform paths.

The addition of multiple installation locations (npm global, Scoop, Local Programs, Chocolatey) significantly improves Claude CLI discovery on Windows. The inclusion of both .exe and .cmd extensions is correct for covering different installation methods.

---

297-310: LGTM - Registry output parsing looks correct.

The regex handles both REG_SZ and REG_EXPAND_SZ types and properly trims whitespace. The early return for empty or error output is appropriate.

---

326-337: LGTM - Environment variable expansion is correctly implemented.

The early return when no % is present avoids unnecessary processing. Returning the original placeholder for undefined variables is safe behavior.

---

462-498: LGTM - nvm-windows detection is well implemented.

Good handling of:

• NVM_HOME environment variable override
• Proper version directory filtering with regex
• Descending version sort (newest first)
• Graceful error handling for directory read failures

---

935-1047: Detection order prioritizes automatic discovery over user config on Windows.

The new Windows detection order places user config at position 6 (lowest priority), which differs from other tools like Python/Git where user config is priority 1. This is intentional based on PR objectives (fixing the race condition), but the behavior difference between tools may be surprising.

However, looking at getToolInfo() (lines 2147-2165), user config IS checked first there before calling detectToolPath(). So the effective priority is correct - this order only applies when user config is not set or invalid.

---

2079-2114: Effective race condition fix by reading settings from disk.

The fallback to readSettingsFile() when in-memory config is empty correctly handles the case where getToolInfo() is called before configureTools() completes. This addresses the core issue described in the PR objectives.

One consideration: this introduces disk I/O on every getToolInfo() call when in-memory config is empty. For the race condition scenario, this only happens once at startup before settings load.

---

2147-2165: LGTM - Race condition fix is properly integrated.

The updated getToolInfo() now:

1. Checks user-configured path first (from memory or disk)
2. Validates the path before using it
3. Falls back to detection only if user config is not set or invalid

This correctly addresses the Windows GUI launch race condition while maintaining expected behavior for user-configured paths.

---

30-30: The readSettingsFile import is correctly exported from settings-utils.

The import statement on line 30 properly references an exported function from ./settings-utils with the correct signature: export function readSettingsFile(): Record<string, unknown> | undefined. The function is used as expected in the new getUserConfiguredPath method.

apps/frontend/src/main/__tests__/cli-tool-manager.test.ts (9)

89-124: Good use of path-agnostic checks for cross-platform test execution.

Using .includes() checks for path segments instead of exact path matching ensures tests pass regardless of which OS runs them.

---

362-374: Good path-agnostic assertions for cross-platform compatibility.

The tests correctly verify path components rather than exact paths, allowing tests to pass on Windows where path.join uses backslashes even when the mocked platform is Linux.

---

501-552: Comprehensive tests for parseRegOutput function.

Good coverage including:

• Standard REG_EXPAND_SZ output
• REG_SZ type variant
• Empty/error output handling
• Paths with spaces

---

554-622: Good test coverage for expandWindowsEnvVars.

Tests cover the key environment variables (USERPROFILE, APPDATA, LOCALAPPDATA, SystemRoot) and edge cases (no variables, undefined variables).

---

624-723: Thorough tests for getWindowsRegistryPath.

Good coverage of:

• Non-Windows platform guard
• User and system PATH combination
• Registry access failures
• Missing user PATH scenario

---

725-834: Comprehensive tests for findClaudeInRegistryPath.

Tests verify:

• Finding .exe and .cmd variants
• Extension checking order
• Negative case (not found)
• Platform guard

---

861-1008: Good test coverage for nvm-windows paths.

Tests cover:

• Default location detection
• NVM_HOME override
• npm global packages location
• Version sorting
• Error handling
• Non-version directory filtering
• Platform guard

---

1054-1219: Excellent tests for Windows detection order.

Tests verify:

• Registry PATH is checked before process.env.PATH
• Fallback to known paths when registry fails
• Official installer location (.local/bin)
• User config as last resort
• macOS and Linux detection order is preserved

---

1225-1277: Good coverage of Windows known paths in getClaudeDetectionPaths.

Tests verify all expected installation locations are included and that both .exe and .cmd extensions are checked.

[VDT-91]

Rebased onto latest develop

This PR has been rebased onto the latest develop branch to resolve merge conflicts. The previous commits were consolidated into a single focused commit.

Summary of Changes

The core fix addresses the Windows GUI app PATH inheritance issue reported by @xytras1:

Problem: Electron GUI apps don't inherit the shell's PATH environment variable. Even though claude --version works in terminal, the desktop app fails to find Claude CLI.

Solution: Read the TRUE Windows PATH directly from the Windows Registry:

1. Registry PATH Reading

   • parseRegOutput() - Parse reg.exe query output
   • expandWindowsEnvVars() - Expand %USERPROFILE%, %APPDATA%, etc.
   • getWindowsRegistryPath() - Read from HKLM (System) + HKCU (User)
   • findClaudeInRegistryPath() - Search for Claude in Registry PATH

2. nvm-windows Support

   • getNvmWindowsPaths() - Support for nvm-windows installations (%APPDATA%\nvm\vX.X.X\)

3. Expanded Known Paths

   • Scoop: ~\scoop\shims\
   • Chocolatey: C:\ProgramData\chocolatey\bin\
   • npm global: %APPDATA%\npm\
   • Official installer: %LOCALAPPDATA%\Programs\claude\

4. Updated Detection Order

   1. Windows Registry PATH (TRUE system PATH)
   2. User configuration (fallback)
   3. System PATH (augmented)
   4. where.exe lookup
   5. nvm-windows paths
   6. Known installation paths
   

The Registry PATH is now checked FIRST on Windows, which should resolve the issue where Claude is installed and working in terminal but not found by the Electron app.

/cc @xytras1 - Would appreciate if you could test this fix when it's merged!

[coderabbitai]

Actionable comments posted: 3

🤖 Fix all issues with AI agents

In @apps/frontend/src/main/cli-tool-manager.ts:
- Around line 328-373: The getWindowsRegistryPath function currently pushes
System PATH before User PATH, reversing Windows' precedence; change the logic so
the User PATH is applied before the System PATH (either query HKCU first, or
push userPath before systemPath or use unshift for userPath) so that
expandWindowsEnvVars(parseRegOutput(...)) for the user registry entry ends up
earlier in the returned paths array; keep error handling and the final join(';')
intact.
- Around line 457-496: getNvmWindowsPaths duplicates the version
sorting/validation logic from sortNvmVersionDirs and only checks
startsWith('v'), allowing invalid dirs; remove the inline sort and validation
and instead call the existing sortNvmVersionDirs helper to produce versionDirs
(ensuring you pass the raw directory names or Dirent list as expected), keep the
initial existsSync/readdirSync and Dirent filtering for isDirectory, then feed
the filtered names into sortNvmVersionDirs so you get the same
/^v\d+\.\d+\.\d+$/ validation and descending semver sort before building the
claude paths.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between aee3a63 and e552099.

📒 Files selected for processing (1)

• apps/frontend/src/main/cli-tool-manager.ts

🧰 Additional context used

📓 Path-based instructions (3)

apps/frontend/src/**/*.{ts,tsx,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings

Files:

• apps/frontend/src/main/cli-tool-manager.ts

apps/frontend/src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Use useTranslation() hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components

Files:

• apps/frontend/src/main/cli-tool-manager.ts

apps/frontend/**/*.{ts,tsx}

⚙️ CodeRabbit configuration file

apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.

Files:

• apps/frontend/src/main/cli-tool-manager.ts

🧠 Learnings (1)

📓 Common learnings

Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:48.743Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings that should be localized) can be deferred to future i18n cleanup passes rather than requiring immediate fixes in PRs that don't introduce new i18n violations.

🧬 Code graph analysis (1)

apps/frontend/src/main/cli-tool-manager.ts (2)

apps/frontend/src/main/env-utils.ts (3)

• existsAsync (29-36)
• findExecutable (252-273)
• findExecutableAsync (411-430)

apps/frontend/src/shared/types/cli.ts (1)

• ToolDetectionResult (12-25)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: CodeQL (python)
• GitHub Check: CodeQL (javascript-typescript)

🔇 Additional comments (6)

apps/frontend/src/main/cli-tool-manager.ts (6)

154-181: LGTM!

Good coverage of Windows installation methods (official installer, npm global, Scoop, Chocolatey, Program Files) and simplified Unix paths. The comment about nvm-windows being added dynamically is helpful for maintainability.

---

284-316: LGTM!

The registry output parsing and environment variable expansion are correctly implemented. The regex pattern handles both REG_SZ and REG_EXPAND_SZ types, and undefined environment variables are preserved (correct fallback behavior).

---

383-411: LGTM!

The extension search order (.exe, .cmd, .bat, then extensionless) correctly prioritizes Windows-native executables over potential bash/shell scripts, consistent with findExecutable in env-utils.ts.

---

948-1062: LGTM!

The updated detection priority correctly addresses the race condition by:

1. Checking Windows Registry PATH first (which GUI apps don't inherit)
2. Moving user configuration to step 2 as a fallback
3. Adding nvm-windows path detection

The detection flow is well-structured with appropriate platform guards.

---

1490-1504: Detection priority mirrors sync version correctly.

The async implementation maintains the same detection priority as the sync version. Note that the blocking issue with findClaudeInRegistryPathAsync (noted earlier) affects this code path as well.

---

2082-2100: LGTM!

Clean export wrapper with helpful documentation and examples.

[VDT-91]

Addressed CodeRabbit Review Feedback

Pushed fixes for the review comments:

✅ Fixed Issues

1. Async function uses sync registry call (Major)

   • Created getWindowsRegistryPathAsync() using execAsync
   • Updated findClaudeInRegistryPathAsync() to use it
   • Now fully non-blocking

2. Empty string extension (Major)

   • Removed '' from extensions array
   • Updated JSDoc to accurately describe behavior
   • Now only checks: .exe, .cmd, .bat

3. Duplicated sorting logic (Nitpick)

   • Refactored getNvmWindowsPaths() to reuse sortNvmVersionDirs()
   • Added proper semver validation (filters invalid dirs like vbackup)

❌ Not Changed (Verified Correct)

4. PATH ordering - CodeRabbit suggested User PATH before System PATH, but this is incorrect. Per SS64 Windows Environment Variables:

   "The User path is appended to the system path"

   Windows constructs PATH as: System PATH + User PATH. Our implementation is correct.

All changes verified with npm run typecheck ✅

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e552099 and cbe5a65.

📒 Files selected for processing (1)

• apps/frontend/src/main/cli-tool-manager.ts

🧰 Additional context used

📓 Path-based instructions (3)

apps/frontend/src/**/*.{ts,tsx,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings

Files:

• apps/frontend/src/main/cli-tool-manager.ts

apps/frontend/src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Use useTranslation() hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components

Files:

• apps/frontend/src/main/cli-tool-manager.ts

apps/frontend/**/*.{ts,tsx}

⚙️ CodeRabbit configuration file

apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.

Files:

• apps/frontend/src/main/cli-tool-manager.ts

🧠 Learnings (1)

📓 Common learnings

Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:48.743Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings that should be localized) can be deferred to future i18n cleanup passes rather than requiring immediate fixes in PRs that don't introduce new i18n violations.

🧬 Code graph analysis (1)

apps/frontend/src/main/cli-tool-manager.ts (2)

apps/frontend/src/main/env-utils.ts (3)

• existsAsync (29-36)
• findExecutable (252-273)
• findExecutableAsync (411-430)

apps/frontend/src/shared/types/cli.ts (1)

• ToolDetectionResult (12-25)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: CodeQL (python)
• GitHub Check: CodeQL (javascript-typescript)

🔇 Additional comments (8)

apps/frontend/src/main/cli-tool-manager.ts (8)

154-185: Comprehensive Windows path coverage for Claude CLI detection.

The expanded path arrays cover multiple installation methods (official installer, npm, Scoop, Chocolatey, Program Files) which significantly improves detection reliability. The separation of windowsPaths and unixPaths with platform-based selection is clean.

Note: The hardcoded C:\ paths (lines 168-172) assume the system drive is C:. This is acceptable since the majority of Windows installations use C: and the detection has multiple fallbacks.

---

284-294: LGTM!

The regex correctly parses both REG_SZ and REG_EXPAND_SZ value types from registry output. The error detection via includes('ERROR:') is sufficient for this use case.

---

308-316: LGTM!

The environment variable expansion correctly handles the %VAR% pattern and gracefully preserves unresolved variables.

---

438-507: LGTM!

Both sync and async implementations correctly search for Claude executables in registry PATH directories. The extension priority (.exe, .cmd, .bat) is sensible, and the error handling for inaccessible paths is appropriate.

---

519-548: Good integration with nvm-windows.

The function correctly enumerates nvm-windows version directories and reuses sortNvmVersionDirs for proper semver validation and sorting. This ensures the newest Node version is checked first.

---

1004-1015: Core fix for Windows GUI launch race condition.

The Windows Registry PATH detection at position #1 correctly addresses the root cause: Windows GUI-launched Electron apps don't inherit the shell's PATH environment. Reading from the registry (HKLM\...\Environment\Path and HKCU\Environment\Path) provides the authoritative Windows PATH that includes user-installed CLIs.

This is the key fix that enables Claude CLI detection on first startup without waiting for settings to load.

---

1546-1557: LGTM!

The async detection correctly uses findClaudeInRegistryPathAsync which internally uses execAsync for non-blocking registry reads. This maintains consistency with the sync version while being safe for the Electron main process.

---

1066-1076: Good nvm-windows fallback.

The nvm-windows path enumeration at position #6 provides a fallback for scenarios where Claude is installed via npm in an nvm-managed Node.js environment that might not be reflected in the registry PATH. The newest Node version is checked first due to sortNvmVersionDirs.

[VDT-91]

Latest Commit: Fix Child Process PATH Environment

This commit (b6eddf8) addresses an issue discovered during testing where Claude CLI was successfully found via Registry PATH, but validation failed because claude.cmd is a wrapper script that calls node, and node wasn't in the child process's PATH.

Root Cause

When Electron runs claude.cmd --version to validate the CLI, it spawns a child process. The previous fix only read the Registry PATH for finding Claude, but didn't pass it to child processes during validation/execution.

Solution

• Centralized Registry PATH helpers in env-utils.ts (previously duplicated in cli-tool-manager.ts)
• Updated getAugmentedEnv() and getAugmentedEnvAsync() to include Windows Registry PATH
• Added caching for Registry PATH queries to avoid repeated registry reads
• All child processes now have access to the full Windows PATH

Testing

Tested by starting the app from a fresh command prompt (not inheriting shell PATH):

[Claude CLI] Found via Registry PATH: C:\Users\sondree\AppData\Roaming\npm\claude.cmd
[Claude Code] Detection result: {
  "found": true,
  "path": "C:\Users\sondree\AppData\Roaming\npm\claude.cmd",
  "version": "2.1.5",
  "source": "system-path",
  "message": "Using Claude CLI from Windows PATH: ..."
}

Before this fix, validation would fail with: '"node"' is not recognized as an internal or external command

Files Changed

• apps/frontend/src/main/env-utils.ts - Added Registry PATH helpers and updated env augmentation
• apps/frontend/src/main/cli-tool-manager.ts - Now imports from env-utils.ts, removed duplicates

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In @apps/frontend/src/main/env-utils.ts:
- Around line 16-20: Tests fail because the child_process mock used by
env-utils.ts omits the exec export which env-utils imports and uses; update the
vi.mock for 'child_process' in the test (used by
apps/frontend/src/main/__tests__/env-handlers-claude-cli.test.ts) to include an
exec implementation that mirrors execFile mock behavior (accepting (cmd, opts,
cb) signature, normalizing optional callback parameter, invoking the callback
asynchronously with (null, '', '') and returning a stubbed object with on
method) so calls to exec from env-utils.ts succeed in tests.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cbe5a65 and b6eddf8.

📒 Files selected for processing (2)

• apps/frontend/src/main/cli-tool-manager.ts
• apps/frontend/src/main/env-utils.ts

🧰 Additional context used

📓 Path-based instructions (3)

apps/frontend/src/**/*.{ts,tsx,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings

Files:

• apps/frontend/src/main/cli-tool-manager.ts
• apps/frontend/src/main/env-utils.ts

apps/frontend/src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Use useTranslation() hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components

Files:

• apps/frontend/src/main/cli-tool-manager.ts
• apps/frontend/src/main/env-utils.ts

apps/frontend/**/*.{ts,tsx}

⚙️ CodeRabbit configuration file

apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.

Files:

• apps/frontend/src/main/cli-tool-manager.ts
• apps/frontend/src/main/env-utils.ts

🧠 Learnings (1)

📓 Common learnings

Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:48.743Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings that should be localized) can be deferred to future i18n cleanup passes rather than requiring immediate fixes in PRs that don't introduce new i18n violations.

🧬 Code graph analysis (1)

apps/frontend/src/main/cli-tool-manager.ts (1)

apps/frontend/src/main/env-utils.ts (5)

• getWindowsRegistryPath (106-154)
• getWindowsRegistryPathAsync (164-224)
• existsAsync (30-37)
• findExecutable (463-484)
• findExecutableAsync (635-654)

🪛 GitHub Actions: CI

apps/frontend/src/main/cli-tool-manager.ts

[error] 298-300: Find Claude in registry path failed due to missing mock export getWindowsRegistryPath. Tests referencing Windows registry path resolution cannot proceed.

🪛 GitHub Check: test-frontend

apps/frontend/src/main/cli-tool-manager.ts

[failure] 338-338: src/main/tests/cli-tool-manager.test.ts > cli-tool-manager - Claude CLI async Windows where.exe detection > should handle async where.exe errors gracefully
Error: [vitest] No "getWindowsRegistryPathAsync" export is defined on the "../env-utils" mock. Did you forget to return it from "vi.mock"?
If you need to partially mock a module, you can use "importOriginal" helper inside:

vi.mock(import("../env-utils"), async (importOriginal) => {
const actual = await importOriginal()
return {
...actual,
// your mocked methods
}
})

❯ findClaudeInRegistryPathAsync src/main/cli-tool-manager.ts:338:30
❯ CLIToolManager.detectClaudeAsync src/main/cli-tool-manager.ts:1404:40
❯ CLIToolManager.detectToolPathAsync src/main/cli-tool-manager.ts:1193:21
❯ CLIToolManager.getToolPathAsync src/main/cli-tool-manager.ts:1166:31
❯ Module.getToolPathAsync src/main/cli-tool-manager.ts:2030:25
❯ src/main/tests/cli-tool-manager.test.ts:736:26

---

[failure] 338-338: src/main/tests/cli-tool-manager.test.ts > cli-tool-manager - Claude CLI async Windows where.exe detection > should detect Claude CLI via where.exe asynchronously
Error: [vitest] No "getWindowsRegistryPathAsync" export is defined on the "../env-utils" mock. Did you forget to return it from "vi.mock"?
If you need to partially mock a module, you can use "importOriginal" helper inside:

vi.mock(import("../env-utils"), async (importOriginal) => {
const actual = await importOriginal()
return {
...actual,
// your mocked methods
}
})

❯ findClaudeInRegistryPathAsync src/main/cli-tool-manager.ts:338:30
❯ CLIToolManager.detectClaudeAsync src/main/cli-tool-manager.ts:1404:40
❯ CLIToolManager.detectToolPathAsync src/main/cli-tool-manager.ts:1193:21
❯ CLIToolManager.getToolPathAsync src/main/cli-tool-manager.ts:1166:31
❯ Module.getToolPathAsync src/main/cli-tool-manager.ts:2030:25
❯ src/main/tests/cli-tool-manager.test.ts:720:11

---

[failure] 298-298: src/main/tests/cli-tool-manager.test.ts > cli-tool-manager - Claude CLI Windows where.exe detection > should handle where.exe execution errors gracefully
Error: [vitest] No "getWindowsRegistryPath" export is defined on the "../env-utils" mock. Did you forget to return it from "vi.mock"?
If you need to partially mock a module, you can use "importOriginal" helper inside:

vi.mock(import("../env-utils"), async (importOriginal) => {
const actual = await importOriginal()
return {
...actual,
// your mocked methods
}
})

❯ findClaudeInRegistryPath src/main/cli-tool-manager.ts:298:24
❯ CLIToolManager.detectClaude src/main/cli-tool-manager.ts:862:34
❯ CLIToolManager.detectToolPath src/main/cli-tool-manager.ts:492:21
❯ CLIToolManager.getToolInfo src/main/cli-tool-manager.ts:1892:17
❯ Module.getToolInfo src/main/cli-tool-manager.ts:1968:25
❯ src/main/tests/cli-tool-manager.test.ts:686:20

---

[failure] 298-298: src/main/tests/cli-tool-manager.test.ts > cli-tool-manager - Claude CLI Windows where.exe detection > should prefer .cmd/.exe paths when where.exe returns multiple results
Error: [vitest] No "getWindowsRegistryPath" export is defined on the "../env-utils" mock. Did you forget to return it from "vi.mock"?
If you need to partially mock a module, you can use "importOriginal" helper inside:

vi.mock(import("../env-utils"), async (importOriginal) => {
const actual = await importOriginal()
return {
...actual,
// your mocked methods
}
})

❯ findClaudeInRegistryPath src/main/cli-tool-manager.ts:298:24
❯ CLIToolManager.detectClaude src/main/cli-tool-manager.ts:862:34
❯ CLIToolManager.detectToolPath src/main/cli-tool-manager.ts:492:21
❯ CLIToolManager.getToolInfo src/main/cli-tool-manager.ts:1892:17
❯ Module.getToolInfo src/main/cli-tool-manager.ts:1968:25
❯ src/main/tests/cli-tool-manager.test.ts:668:20

---

[failure] 298-298: src/main/tests/cli-tool-manager.test.ts > cli-tool-manager - Claude CLI Windows where.exe detection > should fallback to platform paths if where.exe fails
Error: [vitest] No "getWindowsRegistryPath" export is defined on the "../env-utils" mock. Did you forget to return it from "vi.mock"?
If you need to partially mock a module, you can use "importOriginal" helper inside:

vi.mock(import("../env-utils"), async (importOriginal) => {
const actual = await importOriginal()
return {
...actual,
// your mocked methods
}
})

❯ findClaudeInRegistryPath src/main/cli-tool-manager.ts:298:24
❯ CLIToolManager.detectClaude src/main/cli-tool-manager.ts:862:34
❯ CLIToolManager.detectToolPath src/main/cli-tool-manager.ts:492:21
❯ CLIToolManager.getToolInfo src/main/cli-tool-manager.ts:1892:17
❯ Module.getToolInfo src/main/cli-tool-manager.ts:1968:25
❯ src/main/tests/cli-tool-manager.test.ts:647:20

---

[failure] 298-298: src/main/tests/cli-tool-manager.test.ts > cli-tool-manager - Claude CLI Windows where.exe detection > should validate Claude CLI before returning where.exe path
Error: [vitest] No "getWindowsRegistryPath" export is defined on the "../env-utils" mock. Did you forget to return it from "vi.mock"?
If you need to partially mock a module, you can use "importOriginal" helper inside:

vi.mock(import("../env-utils"), async (importOriginal) => {
const actual = await importOriginal()
return {
...actual,
// your mocked methods
}
})

❯ findClaudeInRegistryPath src/main/cli-tool-manager.ts:298:24
❯ CLIToolManager.detectClaude src/main/cli-tool-manager.ts:862:34
❯ CLIToolManager.detectToolPath src/main/cli-tool-manager.ts:492:21
❯ CLIToolManager.getToolInfo src/main/cli-tool-manager.ts:1892:17
❯ Module.getToolInfo src/main/cli-tool-manager.ts:1968:25
❯ src/main/tests/cli-tool-manager.test.ts:622:20

---

[failure] 298-298: src/main/tests/cli-tool-manager.test.ts > cli-tool-manager - Claude CLI Windows where.exe detection > should detect Claude CLI via where.exe when not in PATH
Error: [vitest] No "getWindowsRegistryPath" export is defined on the "../env-utils" mock. Did you forget to return it from "vi.mock"?
If you need to partially mock a module, you can use "importOriginal" helper inside:

vi.mock(import("../env-utils"), async (importOriginal) => {
const actual = await importOriginal()
return {
...actual,
// your mocked methods
}
})

❯ findClaudeInRegistryPath src/main/cli-tool-manager.ts:298:24
❯ CLIToolManager.detectClaude src/main/cli-tool-manager.ts:862:34
❯ CLIToolManager.detectToolPath src/main/cli-tool-manager.ts:492:21
❯ CLIToolManager.getToolInfo src/main/cli-tool-manager.ts:1892:17
❯ Module.getToolInfo src/main/cli-tool-manager.ts:1968:25
❯ src/main/tests/cli-tool-manager.test.ts:573:20

---

[failure] 298-298: src/main/tests/cli-tool-manager.test.ts > cli-tool-manager - Claude CLI NVM detection > Platform-specific path detection > should detect Claude CLI in Windows AppData npm global path
Error: [vitest] No "getWindowsRegistryPath" export is defined on the "../env-utils" mock. Did you forget to return it from "vi.mock"?
If you need to partially mock a module, you can use "importOriginal" helper inside:

vi.mock(import("../env-utils"), async (importOriginal) => {
const actual = await importOriginal()
return {
...actual,
// your mocked methods
}
})

❯ findClaudeInRegistryPath src/main/cli-tool-manager.ts:298:24
❯ CLIToolManager.detectClaude src/main/cli-tool-manager.ts:862:34
❯ CLIToolManager.detectToolPath src/main/cli-tool-manager.ts:492:21
❯ CLIToolManager.getToolInfo src/main/cli-tool-manager.ts:1892:17
❯ Module.getToolInfo src/main/cli-tool-manager.ts:1968:25
❯ src/main/tests/cli-tool-manager.test.ts:341:22

---

[failure] 298-298: src/main/tests/cli-tool-manager.test.ts > cli-tool-manager - Claude CLI NVM detection > NVM path detection on Unix/Linux/macOS > should skip NVM path detection on Windows
Error: [vitest] No "getWindowsRegistryPath" export is defined on the "../env-utils" mock. Did you forget to return it from "vi.mock"?
If you need to partially mock a module, you can use "importOriginal" helper inside:

vi.mock(import("../env-utils"), async (importOriginal) => {
const actual = await importOriginal()
return {
...actual,
// your mocked methods
}
})

❯ findClaudeInRegistryPath src/main/cli-tool-manager.ts:298:24
❯ CLIToolManager.detectClaude src/main/cli-tool-manager.ts:862:34
❯ CLIToolManager.detectToolPath src/main/cli-tool-manager.ts:492:21
❯ CLIToolManager.getToolInfo src/main/cli-tool-manager.ts:1892:17
❯ Module.getToolInfo src/main/cli-tool-manager.ts:1968:25
❯ src/main/tests/cli-tool-manager.test.ts:210:22

apps/frontend/src/main/env-utils.ts

[failure] 20-20: src/main/tests/env-handlers-claude-cli.test.ts
Error: [vitest] No "exec" export is defined on the "child_process" mock. Did you forget to return it from "vi.mock"?
If you need to partially mock a module, you can use "importOriginal" helper inside:

vi.mock(import("child_process"), async (importOriginal) => {
const actual = await importOriginal()
return {
...actual,
// your mocked methods
}
})

❯ src/main/env-utils.ts:20:29
❯ src/main/ipc-handlers/env-handlers.ts:13:1

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: CodeQL (javascript-typescript)
• GitHub Check: CodeQL (python)

🔇 Additional comments (13)

apps/frontend/src/main/cli-tool-manager.ts (7)

166-197: LGTM! Comprehensive Windows path coverage.

The updated getClaudeDetectionPaths now includes paths for multiple Windows installation methods (official installer, npm global, Scoop, Chocolatey, Program Files). The separation of windowsPaths and unixPaths with platform selection is clean.

---

293-322: LGTM! Registry-based Claude detection is well-implemented.

The function correctly reads the true Windows PATH from Registry and searches for Claude with appropriate extensions. Platform guard and error handling are in place.

---

332-362: LGTM! Async variant properly uses non-blocking operations.

The async version correctly uses getWindowsRegistryPathAsync() and existsAsync() to avoid blocking the Electron main process.

---

374-403: LGTM! nvm-windows path enumeration is correct.

The function properly enumerates Claude paths from nvm-windows installations. Reusing sortNvmVersionDirs for semver validation ensures consistency with Unix NVM handling. The sync directory read is acceptable here since it's reading a small local directory.

---

859-870: LGTM! Registry PATH prioritized correctly for Windows GUI apps.

The detection now correctly checks Windows Registry PATH first, which contains the true system PATH that GUI apps don't inherit from shell. This directly addresses the race condition fix described in the PR objectives.

---

921-931: LGTM! nvm-windows detection integrated correctly.

The nvm-windows paths are checked after system PATH methods but before Unix NVM and platform paths, which is appropriate for Windows-specific detection.

---

29-41: Missing mocks for registry functions need verification against actual test failures.

The main file imports getWindowsRegistryPath and getWindowsRegistryPathAsync from env-utils (lines 39-40), and these are used in the exported functions findClaudeInRegistryPath() and findClaudeInRegistryPathAsync(). However, these functions are not currently imported or tested in the test file. The test file only imports and tests: getToolInfo, getToolPathAsync, clearToolCache, getClaudeDetectionPaths, sortNvmVersionDirs, and buildClaudeDetectionResult.

Additionally, parseRegOutput and expandWindowsEnvVars are imported in the main file but not actually used anywhere in the code—they appear to be unused imports.

Confirm whether the referenced "7 test failures" actually occur, and clarify which test cases are affected by these missing mocks.

apps/frontend/src/main/env-utils.ts (6)

60-70: LGTM! Robust registry output parsing.

The function correctly handles both REG_SZ and REG_EXPAND_SZ types and checks for error responses. The regex properly captures the PATH value.

---

84-92: LGTM! Safe environment variable expansion.

The function correctly expands %VAR% patterns while preserving unmatched variables (returns original match if env var not found), which is defensive against missing variables.

---

106-154: LGTM! Well-implemented sync Registry PATH reader.

The function properly reads both system (HKLM) and user (HKCU) PATH with:

• Session-scoped caching to avoid repeated registry queries
• Graceful fallback when one registry read fails
• Proper environment variable expansion
• Reasonable timeout (5000ms)

---

164-224: LGTM! Async version with proper concurrency handling.

The promise-based deduplication pattern (lines 174-177) correctly prevents concurrent registry calls when multiple callers request the PATH simultaneously. The finally block appropriately clears the promise cache.

---

407-418: LGTM! Registry PATH correctly integrated into environment augmentation.

The Registry PATH is prepended to give it priority over any inherited PATH, which is the correct behavior for Windows GUI apps. The conditional merge handles the case when currentPath is empty.

---

577-588: LGTM! Async version mirrors sync behavior correctly.

Uses getWindowsRegistryPathAsync() for non-blocking Registry access while maintaining the same prepending logic.

[VDT-91]

CI Fix: Added Mock Functions for Registry PATH Helpers

The test-frontend CI was failing because the cli-tool-manager.test.ts mocks env-utils module, but didn't include the new exports:

• getWindowsRegistryPath
• getWindowsRegistryPathAsync

Added these to the mock with vi.fn(() => null) and vi.fn(() => Promise.resolve(null)) to return null (avoiding actual registry reads in tests).

The cli-tool-manager tests now pass. The remaining test failures in the CI are pre-existing issues in claude-integration-handler.test.ts related to Windows path separators - unrelated to this PR.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In @apps/frontend/src/main/cli-tool-manager.ts:
- Around line 291-320: The Registry-derived PATH entries in
findClaudeInRegistryPath are not security-validated and one detection log uses
console.log; update the function to call the existing isSecurePath(...) on each
directory (or on the resolved candidatePath) before accepting it and skip any
insecure entries, and replace the console.log call with console.warn to match
the file's logging convention; use the same helpers already referenced
(getWindowsRegistryPath, path.join, existsSync) and ensure insecure candidates
are ignored and, if desired, emit a console.warn about skipping insecure
registry PATH entries.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b6eddf8 and ec3ef2a.

📒 Files selected for processing (2)

• apps/frontend/src/main/__tests__/cli-tool-manager.test.ts
• apps/frontend/src/main/cli-tool-manager.ts

🧰 Additional context used

📓 Path-based instructions (3)

apps/frontend/src/**/*.{ts,tsx,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings

Files:

• apps/frontend/src/main/__tests__/cli-tool-manager.test.ts
• apps/frontend/src/main/cli-tool-manager.ts

apps/frontend/src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Use useTranslation() hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components

Files:

• apps/frontend/src/main/__tests__/cli-tool-manager.test.ts
• apps/frontend/src/main/cli-tool-manager.ts

apps/frontend/**/*.{ts,tsx}

⚙️ CodeRabbit configuration file

apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.

Files:

• apps/frontend/src/main/__tests__/cli-tool-manager.test.ts
• apps/frontend/src/main/cli-tool-manager.ts

🧠 Learnings (1)

📓 Common learnings

Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:48.743Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings that should be localized) can be deferred to future i18n cleanup passes rather than requiring immediate fixes in PRs that don't introduce new i18n violations.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: CodeQL (javascript-typescript)
• GitHub Check: CodeQL (python)

🔇 Additional comments (9)

apps/frontend/src/main/cli-tool-manager.ts (8)

29-39: LGTM! Imports are well-organized and aligned with the new Registry PATH functionality.

---

164-195: LGTM! Comprehensive Windows path coverage.

The detection paths cover multiple installation methods (npm, Scoop, Chocolatey, official installer) which addresses the various ways users might have Claude CLI installed on Windows.

---

330-360: Same considerations as sync version apply here.

The async variant mirrors the sync logic correctly. Apply the same security validation and logging consistency improvements suggested for findClaudeInRegistryPath.

---

372-401: LGTM! Good reuse of sortNvmVersionDirs for consistent semver validation.

The implementation correctly filters out invalid version directories (e.g., vbackup, vold) by reusing the existing semver validation logic. The fallback for APPDATA and multiple extension variants ensure robust detection across nvm-windows configurations.

---

857-868: LGTM! Registry PATH detection correctly prioritized for Windows GUI launch fix.

This directly addresses the PR objective: GUI apps don't inherit the shell's PATH, so reading from Registry ensures Claude CLI is found on Windows desktop/Start Menu launches.

---

919-929: LGTM! nvm-windows detection properly integrated into the flow.

---

1399-1410: LGTM! Async Registry PATH detection mirrors sync implementation.

The async variant properly uses findClaudeInRegistryPathAsync and validateClaudeAsync to avoid blocking the Electron main process during detection.

---

1461-1471: LGTM! Async nvm-windows detection properly uses non-blocking operations.

apps/frontend/src/main/__tests__/cli-tool-manager.test.ts (1)

129-135: LGTM! Mocks correctly isolate tests from Windows Registry operations.

The added mocks for existsAsync and the Registry PATH helpers ensure unit tests don't perform actual registry reads. The null/identity return values appropriately simulate "registry unavailable" conditions. All mocked functions (parseRegOutput, getWindowsRegistryPath, getWindowsRegistryPathAsync, expandWindowsEnvVars, and existsAsync) are exported from env-utils.ts and are necessary for proper test isolation.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Consider security validation for Registry PATH entries.

The user-configured path validation uses isSecurePath() (line 876), but paths discovered from Registry PATH are not validated. While the registry is generally trusted, a compromised PATH entry could lead to executing unintended binaries.

Additionally, Line 310 uses console.log while the rest of the file uses console.warn for logging detection messages. Consider using console.warn for consistency.

♻️ Suggested security check and logging consistency

         try {
           if (existsSync(candidatePath)) {
+            if (!isSecurePath(candidatePath)) {
+              console.warn(`[Claude CLI] Registry PATH entry failed security validation, skipping: ${candidatePath}`);
+              continue;
+            }
-            console.log(`[Claude CLI] Found via Registry PATH: ${candidatePath}`);
+            console.warn(`[Claude CLI] Found via Registry PATH: ${candidatePath}`);
             return candidatePath;
           }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	export function findClaudeInRegistryPath(): string | null {
	if (process.platform !== 'win32') {
	return null;
	}
	const registryPath = getWindowsRegistryPath();
	if (!registryPath) {
	return null;
	}
	const pathDirs = registryPath.split(';').filter(Boolean);
	// Standard Windows executable extensions - checked in order of priority
	const extensions = ['.exe', '.cmd', '.bat'];
	for (const dir of pathDirs) {
	for (const ext of extensions) {
	const candidatePath = path.join(dir, `claude${ext}`);
	try {
	if (existsSync(candidatePath)) {
	console.log(`[Claude CLI] Found via Registry PATH: ${candidatePath}`);
	return candidatePath;
	}
	} catch {
	// Skip inaccessible paths
	}
	}
	}
	return null;
	}
	export function findClaudeInRegistryPath(): string | null {
	if (process.platform !== 'win32') {
	return null;
	}
	const registryPath = getWindowsRegistryPath();
	if (!registryPath) {
	return null;
	}
	const pathDirs = registryPath.split(';').filter(Boolean);
	// Standard Windows executable extensions - checked in order of priority
	const extensions = ['.exe', '.cmd', '.bat'];
	for (const dir of pathDirs) {
	for (const ext of extensions) {
	const candidatePath = path.join(dir, `claude${ext}`);
	try {
	if (existsSync(candidatePath)) {
	if (!isSecurePath(candidatePath)) {
	console.warn(`[Claude CLI] Registry PATH entry failed security validation, skipping: ${candidatePath}`);
	continue;
	}
	console.warn(`[Claude CLI] Found via Registry PATH: ${candidatePath}`);
	return candidatePath;
	}
	} catch {
	// Skip inaccessible paths
	}
	}
	}
	return null;
	}

🤖 Prompt for AI Agents

In @apps/frontend/src/main/cli-tool-manager.ts around lines 291 - 320, The
Registry-derived PATH entries in findClaudeInRegistryPath are not
security-validated and one detection log uses console.log; update the function
to call the existing isSecurePath(...) on each directory (or on the resolved
candidatePath) before accepting it and skip any insecure entries, and replace
the console.log call with console.warn to match the file's logging convention;
use the same helpers already referenced (getWindowsRegistryPath, path.join,
existsSync) and ensure insecure candidates are ignored and, if desired, emit a
console.warn about skipping insecure registry PATH entries.

[VDT-91]

CI Fix #2: Added exec/execSync mocks to env-handlers-claude-cli tests

Another test file (env-handlers-claude-cli.test.ts) also needed the exec and execSync mocks added to its child_process mock, since env-utils.ts now imports exec for the async Registry PATH operations.