Repository navigation
[Bug]: Claude Code not detected as installed despite being functional in SubFrame's terminal #35
Description
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
- Install Claude Code via claude install (native install to ~/.local/bin/claude)
- Open SubFrame → Settings → AI Tool
- Active Tool shows "Claude Code (not installed)"
- Changing Start Command to the full path (/Users//.local/bin/claude) and saving does not resolve the issue
- 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
Activity
cosmiceric commentedon Mar 16, 2026
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 commentedon Mar 23, 2026
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 commentedon Mar 23, 2026
@claude - investigate this bug and suggest a fix please
claude commentedon Mar 23, 2026
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
src/main/aiToolManager.tsRoot Cause
In
src/main/aiToolManager.ts,isCommandInstalledAsync()was callingexecFile('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— whereclaude installplaces 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/claudein the Start Command field, the code still piped it throughwhich <path>, which also fails without the proper PATH.Changes Made (
src/main/aiToolManager.ts)Absolute paths (e.g.
/Users/foo/.local/bin/claude):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):terminal.defaultShellsetting, falling back to$SHELL, then/bin/zsh) with the-lflag, so~/.zshrc/~/.bashrcis sourced — matching exactly what SubFrame's terminal sees./^[\w.@-]+$/) before being passed to the shell.Windows: unchanged —
where.exealready works correctly.Why this matches the reporter's scenario
The user had
claudein~/.local/bin, added to PATH only in~/.zshrc. SubFrame was detecting with a bareexecFile(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.|
fix(aiToolManager): use login shell for detection to respect user PATH
cosmiceric commentedon Mar 23, 2026
No worries! Happy to test further if helpful.