Fix menubar installer CLI path lookup#387
Merged
iamtoruk merged 2 commits intoMay 24, 2026
Merged
Conversation
resolvePersistentCodeburnPathFromWhichOutput already guarantees the returned path is absolute and non-npx.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #384 by making the macOS menubar installer resolve a persistent
codeburnbinary from the caller's real PATH instead of a hard-coded Homebrew/system-only PATH.Root cause
codeburn menubarpersists the CLI path so the installed Swift menubar app can keep launchingcodeburnlater from a GUI process. The lookup used:That drops the PATH that successfully launched the installer. Users with global installs under Node version managers such as nvm, fnm, volta, or asdf can run
codeburn menubarfrom their shell, but the installer lookup cannot see thatcodeburnbinary and reports the raw subprocess failure:It also only looked at the first
whichmatch, so a transientnpxshim could mask a later persistent install.What changed
codeburncommand./opt/homebrew/bin,/usr/local/bin,/usr/bin,/bin) without dropping user Node-manager paths.which codeburntowhich -a codeburnand choose the first absolute non-npxmatch./usr/bin/env exited with status 1.Validation
Concrete fixture for the bug path:
Before this change, the installer used a fixed PATH and could not see the nvm entry. With an unavailable lookup, the user-facing CLI error was:
After this change, the same lookup shape keeps the caller PATH and selects the persistent binary:
The only-npx case now returns actionable guidance instead of the raw env failure:
Checks:
Notes:
npm run buildpasses and regeneratessrc/data/litellm-snapshot.json; that generated snapshot refresh was restored because it is unrelated to this fix.