fix(ccusage): resolve nvm node bin path from alias/default#463
Open
devKagan wants to merge 1 commit into
Open
Conversation
devKagan
requested review from
davidarny,
robinebers and
validatedev
as code owners
Collaborator
|
@codex review |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR aims to restore local ccusage-powered “Today / Yesterday / Last 30 Days” lines (notably for the Codex card) by making the ccusage runner discovery more resilient on systems using nvm where ~/.nvm/current/bin is absent, by enriching PATH with an nvm “default” version bin directory.
Changes:
- Add
nvm_default_bin_path()to derive an nvm Node bin directory from~/.nvm/alias/default. - Include the derived nvm default bin path in the ccusage PATH enrichment logic.
- Add unit tests covering version parsing with/without
vprefix and verifying PATH entry inclusion.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+1669
to
+1680
| fn nvm_default_bin_path(home: &Path) -> Option<PathBuf> { | ||
| let alias_path = home.join(".nvm/alias/default"); | ||
| let version = std::fs::read_to_string(&alias_path).ok()?; | ||
| let version = version.trim(); | ||
| if version.is_empty() { | ||
| return None; | ||
| } | ||
| let version = if version.starts_with('v') { | ||
| version.to_string() | ||
| } else { | ||
| format!("v{version}") | ||
| }; |
| ); | ||
| } | ||
|
|
||
| #[test] |
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.
Description
While using openusage after an update, I noticed that the
Today / Yesterday / Last 30 Dayslines had disappeared from the Codex card. I checked my version and also confirmed the version
of a teammate who could still see them — both were on v0.6.23.
After some investigation, I believe I've found the cause —
though I'm not deeply familiar with the codebase, so please let me know if my
analysis is off.
What I think is happening:
On my machine, the Codex CLI is installed via nvm, which places a
codexbinaryat
~/.nvm/versions/node/<version>/bin/codex. When openusage runsbunx @ccusage/codex, bunx appears to strip the package scope and search for abinary named
codexin PATH — finding the Codex CLI instead of the@ccusage/codexnpm package. This causes an immediate failure since the CodexCLI doesn't recognize the
--jsonflag.In principle, the fallback runners (
npm exec,npx) should recover from this.However, the enriched PATH used to locate them includes
~/.nvm/current/bin,which nvm does not appear to create by default — at least not on my setup. As a
result, the fallback runners can't be found either, and all runners are exhausted
silently.
I verified this by creating a
~/.nvm/currentsymlink manually, which restoredthe missing lines immediately. Removing the symlink caused them to disappear again.
Note: the bunx binary conflict itself is not addressed here — but if the fallback
runners are reachable, the failed bunx attempt is already recovered correctly by
the existing logic.
Fix: Read
~/.nvm/alias/defaultto resolve the active nvm version and add~/.nvm/versions/node/<version>/binto the enriched PATH alongside the existing~/.nvm/current/binentry.This affects both the Codex and Claude plugins, as they are the only two pluginsthat call
ctx.host.ccusage.query()to fetch local token usage — all otherplugins retrieve data directly from their respective provider APIs and are
unaffected.
This issue appears to be specific to the Codex plugin. The Claude plugin uses
bunx ccusage(an unscoped package name), so bunx resolves it without conflict.The Codex plugin uses
bunx @ccusage/codex(a scoped package), where bunx stripsthe scope and searches for a
codexbinary — which, if the Codex CLI is installedvia nvm, ends up running the Codex CLI binary rather than downloading the
@ccusage/codexnpm package as intended.I'm not sure how common this setup is, but I hope this helps others in a similar
situation. Happy to adjust anything if I've misunderstood the codebase.
Related Issue
N/A
Type of Change
Testing
bun run buildand it succeededbun run testand all tests passbun tauri devScreenshots
Before (without
~/.nvm/currentsymlink —Today / Yesterday / Last 30 Daysmissing)After (with
~/.nvm/currentsymlink — lines restored)Checklist
mainbranchSummary by cubic
Fix NVM path resolution so
ccusagecan find Node runners when~/.nvm/currentis missing. Restores the Codex/Claude local usage lines whenbunxresolves the wrongcodexbinary.~/.nvm/alias/default(handles versions with/withoutv) and add~/.nvm/versions/node/<version>/binto PATH.npm exec/npxare reachable even ifbunxpicks thecodexCLI instead of@ccusage/codex.Written for commit fa1438e. Summary will update on new commits.