[Bug]: Claude Code not detected as installed despite being functional in SubFrame's terminal

[cosmiceric]

Before you file

• I searched existing issues and didn't find a duplicate
• I'm on the latest version of SubFrame

Operating System

macOS

OS Version

Apple Silicon, Darwin 24.6.0

SubFrame Version

0.5.5-beta

What happened?

SubFrame's AI Tool settings show "Claude Code (not installed)" even though Claude Code is installed and works correctly in SubFrame's built-in terminal.

Expected Behavior:

SubFrame should detect Claude Code as installed when it's available in the shell PATH or when a valid full path is provided in the Start Command field.

Steps to reproduce

1. Install Claude Code via claude install (native install to ~/.local/bin/claude)
2. Open SubFrame → Settings → AI Tool
3. Active Tool shows "Claude Code (not installed)"
4. Changing Start Command to the full path (/Users//.local/bin/claude) and saving does not resolve the issue
5. Opening a SubFrame terminal and running claude works fine

Affected area

No response

Relevant logs or errors

Screenshots or recordings

No response

Additional context

• The system login shell was Bash when SubFrame was first opened. SubFrame's Terminal settings defaulted to Zsh, but its terminals were still launching Bash. Had to
  manually switch SubFrame's default shell to Zsh for claude to be available in the terminal.
• The Claude CLI path (~/.local/bin/claude) is configured in ~/.zshrc but not ~/.bashrc. SubFrame's install detection may be running its check against Bash rather than the
  shell configured in SubFrame's terminal settings, which would explain why it can't find the binary even though it works in the terminal.
• which claude in SubFrame's terminal returns /Users//.local/bin/claude
• The detection issue persists after clicking the refresh icon next to the status message

[cosmiceric]

btw, worked fine on my laptop but not my desktop, I think it's due to zsh vs bash as default terminal and how I had Claude installed

[Codename-11]

Hey @cosmiceric - apologies for the late reply - had a killer week at work this past week! I appreciate you bringing it to my attention, apologies for the issue of course. Let me see if I can troubleshoot/debug - I don't have an apple device on hand - I've hand friends test as needed - but that's not a full solution! I'll follow up :)

[Codename-11]

@claude - investigate this bug and suggest a fix please

[claude]

Claude finished @Codename-11's task in 2m 30s —— View job • claude/issue-35-20260323-1657 • Create PR ➔

---

Fix: Claude Code detection fails due to shell mismatch

• Gather context and understand the issue
• Find the AI tool detection/installation check code — src/main/aiToolManager.ts
• Identify root cause
• Implement fix
• Commit and push

Root Cause

In src/main/aiToolManager.ts, isCommandInstalledAsync() was calling execFile('which', ['claude']) without a shell. On macOS, Electron GUI apps inherit a minimal system PATH (e.g. /usr/bin, /bin) and never source the user's shell profile (~/.zshrc, ~/.bashrc). So ~/.local/bin — where claude install places the binary — was invisible to the check, even though it was perfectly accessible inside SubFrame's terminal (which spawns a login shell and sources the profile).

A second issue: even when a user manually typed an absolute path like /Users/<user>/.local/bin/claude in the Start Command field, the code still piped it through which <path>, which also fails without the proper PATH.

Changes Made (src/main/aiToolManager.ts)

Absolute paths (e.g. /Users/foo/.local/bin/claude):

• Now uses fs.promises.access(path, X_OK) — checks file existence and executability directly, no shell needed. This makes the "full path" workaround in the UI actually work.

Simple command names (e.g. claude, gemini, codex):

• Now spawns the user's configured login shell (terminal.defaultShell setting, falling back to $SHELL, then /bin/zsh) with the -l flag, so ~/.zshrc / ~/.bashrc is sourced — matching exactly what SubFrame's terminal sees.
• Command names are sanitised (/^[\w.@-]+$/) before being passed to the shell.

Windows: unchanged — where.exe already works correctly.

Why this matches the reporter's scenario

The user had claude in ~/.local/bin, added to PATH only in ~/.zshrc. SubFrame was detecting with a bare execFile (no login shell), so PATH didn't include ~/.local/bin → "not installed". After this fix, detection uses the same login shell as the terminal, seeing the same PATH.

---

|

[cosmiceric]

No worries! Happy to test further if helpful.