fix(platform): surface Nix-managed agent CLI install paths - #6334
fix(platform): surface Nix-managed agent CLI install paths#6334xxiaoxiong wants to merge 1 commit into
Conversation
The packaged macOS (and Linux) Desktop app did not discover agent
CLIs installed through nix-darwin `environment.systemPackages` or
per-user `nix profile install`. After launching from Finder and
rescanning, Codex / Claude Code / Gemini resolved cleanly from a
terminal but were reported as not found on `PATH`.
Root cause: in a GUI-launched Electron process the inherited `PATH`
is minimal (launchd does not source the user's shell rc), so
discovery relies on `wellKnownUserToolchainBins` in
`packages/platform/src/toolchain.ts`. The helper's well-known
list covered Homebrew, npm/nvm/fnm/mise/asdf, Deno, Go, pyenv,
Scoop, Volta, Vite+, Kimi, Bun, Cargo and the system Homebrew
locations, but did not include the standard Nix install roots:
- `/run/current-system/sw/bin` (NixOS / nix-darwin system profile)
- `~/.nix-profile/bin` (per-user Nix profile)
Both are documented well-known paths in Nix documentation and are
the canonical locations CLIs installed via `environment.systemPackages`
or `nix profile install` end up in.
Changes:
- `packages/platform/src/toolchain.ts`:
- Add `~/.nix-profile/bin` to the user-level CLI install list
(alongside Deno / Go / pyenv) so single-user Nix installs are
surfaced the same way Homebrew/etc are. Best-effort — a missing
dir contributes nothing; the existing `<dir>/bin` join behaviour
is preserved.
- Add `/run/current-system/sw/bin` to the
`includeSystemBins`-gated block, next to `/opt/homebrew/bin`
and `/usr/local/bin`. Same rationale: a NixOS / nix-darwin
system-installed CLI lives here, and a GUI-launched daemon
needs the explicit probe to find it.
- `packages/platform/tests/index.test.ts`:
- Extend the existing "Deno, Go, pyenv" user-level test to also
assert `~/.nix-profile/bin` is returned.
- Extend both `includeSystemBins` true/false tests to also
assert `/run/current-system/sw/bin` is included / omitted
accordingly. Two assertions in two existing tests, no new
test cases to keep the file dense.
Verified: `pnpm --filter @open-design/platform test` passes 76/76
tests, `pnpm --filter @open-design/platform typecheck` clean.
Fixes nexu-io#6121
Signed-off-by: xxiaoxiong <2482929840@qq.com>
|
Hey @xxiaoxiong — thanks for tracing this back to the shared toolchain resolver and keeping the fix scoped to the two Nix install roots called out in #6121. I’ve queued the normal triage on our side so this can move through review cleanly. |
|
Thanks for the detailed Nix-path analysis — the root-cause write-up makes the scope easy to follow. Could you remap that content into the current PR template with explicit |
|
🧪 Queued for QA validation — this PR has changes that need a manual QA pass before it's merged. Nothing needed from you; we'll update here once it's validated. Thanks for the contribution! 🙏 |
PerishCode
left a comment
There was a problem hiding this comment.
@xxiaoxiong This cleanly extends the shared platform toolchain resolver with the two Nix profile locations while preserving the existing user/system gating and precedence. I verified both changed ranges and their consumers, and ran the platform tests (76/76), platform typecheck, repository guard, and full workspace typecheck successfully. Thanks for the focused fix and the careful regression coverage.
🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.|
Heads-up: PR #6125 from @Pape45 is also open against the same fix path — both PRs change Sharing this so the maintainer team can choose one canonical PR and neither thread ends up doing duplicate work. |
What this PR does
Before this PR:
The packaged macOS (and Linux) Desktop app did not discover agent CLIs installed through nix-darwin
environment.systemPackagesor per-usernix profile install. After launching the app normally from Finder/Applications and rescanning Local CLI agents, Codex, Claude Code, and Gemini were reported as not found onPATH, even thoughcommand -v codex/claude/geminiresolved cleanly from a terminal.After this PR:
Those same Nix-installed CLIs are detected after the next rescan. No user action beyond the standard rescan flow is required.
Why we need it & why it was done this way
#6121 reports the bug. The root cause is architectural, not a typo: in a GUI-launched Electron process the inherited
PATHis minimal (launchd does not source the user's shell rc), so CLI discovery relies onwellKnownUserToolchainBinsinpackages/platform/src/toolchain.tsto surmise the canonical install locations for every popular package manager.That helper already covered Homebrew, npm/nvm/fnm/mise/asdf, Deno, Go, pyenv, Scoop, Volta, Vite+, Kimi, Bun, Cargo and the system Homebrew locations — but did not include the standard Nix install roots. Per the Nix manual, the canonical locations for user-installed / system-installed CLIs are:
/run/current-system/sw/bin— system profile on NixOS / nix-darwin.environment.systemPackagesentries land here.~/.nix-profile/bin— per-user Nix profile.nix profile installentries land here.The fix reuses the existing two-tier structure of
wellKnownUserToolchainBins:~/.nix-profile/binjoins the user-level list (alongside~/.deno/bin,~/go/bin,~/.pyenv/shims). It isincludeSystemBins-independent, mirroring how those sibling user-managed toolchain dirs are surfaced unconditionally./run/current-system/sw/binjoins theincludeSystemBins-gated block, next to/opt/homebrew/binand/usr/local/bin, because it is a system-installed-binaries location. SameincludeSystemBinssemantics: still emitted in the defaultprocess.platform !== "win32"path, still configurable via theincludeSystemBinsopt-in flag.This matches
packages/AGENTS.md:platform's toolchain helper is the single source of truth shared by the daemon agent resolver (apps/daemon/src/agents.ts) and the packaged sidecar PATH builder (apps/packaged/src/sidecars.ts). Both consumers automatically pick up the new entries; neither needs its own change.Tradeoffs
/nix/var/nix/profiles/default/binis omitted. This is the system-default profile on multi-user NixOS installs. The reported bug ([Bug]: Desktop app does not discover agent CLIs installed through Nix #6121) only references/run/current-system/sw/binand~/.nix-profile/bin, so I kept the diff to the two paths the issue named and that the Nix manual documents as the canonical user/system profile roots. Adding/nix/var/nix/profiles/default/binis a one-line follow-up if a maintainer wants the explicit full set; the existing list is already a pragmatic subset of well-known locations, not an exhaustive enumeration./run/current-system/sw/binahead of/opt/homebrew/bin. Existing precedence ordering in the system block (homebrewwins for the macOS "first via Homebrew" convention) is preserved; Nix users who also have Homebrew-installed CLIs with the same name will keep seeing the Homebrew shim. A different ordering is a behavior change beyond this issue's scope.~/.nix-profile/binis added to the user-level CLI list (includeSystemBins: falsepath), not gated. This is intentional and matches siblings (~/.deno/bin,~/go/bin,~/.pyenv/shims) — Nix users should not have to flip a system-bins flag to have their user-installed Nix CLIs discovered.Breaking changes
None. Additive only — two new entries in the well-known list. Existing entries and ordering unchanged.
wellKnownUserToolchainBinsreturns the same set of paths for all existing inputs, plus the new entries when they exist on disk (best-effort, missing dirs contribute nothing).How to verify
pnpm --filter @open-design/platform typecheck pnpm --filter @open-design/platform testBoth pass on this branch. The two existing
wellKnownUserToolchainBinstests have been extended by one assertion each (theDeno, Go, pyenv test now also asserts~/.nix-profile/bin; theincludeSystemBinstrue/false tests now also assert/run/current-system/sw/bin). No new test cases were added to avoid duplication — the two existing tests already cover the code paths being changed.On a NixOS / nix-darwin machine, install any agent CLI through
environment.systemPackagesornix profile install, launch the packaged Desktop app from Finder/Applications, then Settings → Local CLI agents → Rescan. The previously-missing CLI now appears.Fixes #6121