Worker agent spawn fails when Pi is installed via Nix

[chenxin-yan]

Bug

When pi is installed via Nix (e.g. pkgs.pi-coding-agent from nixpkgs), taskplane fails to spawn worker agents with:

Cannot find Pi CLI entrypoint (@mariozechner/pi-coding-agent/dist/cli.js).
Ensure the pi coding agent is installed globally via 'npm install -g @mariozechner/pi-coding-agent'.
npm root -g returned: ...

Tasks fail immediately — not because of the task content, but because the Pi CLI cannot be located.

Root cause

resolvePiCliPath() in path-resolver.ts resolves the Pi CLI by checking npm global roots and static paths (Homebrew, system Node, Windows APPDATA). None of these cover Nix, where pi lives in the Nix store (e.g. /nix/store/<hash>-pi-coding-agent-<ver>/), not in any npm prefix.

Fix

When taskplane is running as a Pi extension, the current process is already node dist/cli.js — so process.argv[1] is exactly the path resolvePiCliPath() is looking for. Adding it as the first candidate requires no subprocess overhead and covers any non-standard install.

This approach is already used in resolveTaskplanePackageFile() (candidate 8), but was not applied consistently to resolvePiCliPath().

A PR with the fix is open: https://github.com/HenryLach/taskplane/pull/new/fix/nix-pi-cli-resolution

Environment

• Pi installed via pkgs.pi-coding-agent from nixpkgs (nix-darwin + home-manager)
• Pi binary resolves to /nix/store/<hash>-pi-coding-agent-<ver>/bin/pi
• taskplane installed via npm into a custom prefix (~/.pi/agent/npm)

[HenryLach]

Fixed in v0.29.0 via the broader #560 remediation — see discussion in PR #520.

[HenryLach]

Reopening this — and I owe @chenxin-yan an apology.

When I closed this on 2026-05-25, I confidently wrote that the fix was already in main at path-resolver.ts:235. I was wrong. That line is in the sibling resolver resolveTaskplanePackageFile — used to locate Taskplane's own files relative to where Pi was loaded — not in resolvePiCliPath, which is the function with the actual job of finding Pi's CLI. The fix you proposed in PR #520 (add process.argv[1] as a resolver candidate so Pi's path is taken from the running parent process rather than enumerated against npm-global paths) was the right diagnosis and the right fix, and it was never actually applied to the function it was meant for.

I was reminded of this today when issue #598 came in with the exact same underlying problem (process.argv[1] ignored, NVM-on-Windows users stranded because child processes inherit a stripped PATH and npm root -g returns empty). Tracing through the resolver in detail made the gap obvious.

Fix landed in PR #599 just now (will be in v0.30.2 when I cut it shortly), and it's exactly your proposed change plus a couple of NVM env-var fallbacks as defense in depth. Full credit for the original insight goes to you — sorry it took a second bug report and 7 weeks to actually believe the diagnosis. If you'd ever consider contributing again I'd be grateful, and I'll be much more careful next time.

[HenryLach]

Fix shipped in v0.30.2. @chenxin-yan \u2014 your original diagnosis from April was exactly right, and the fix that just shipped is what your PR #520 proposed (plus two NVM env-var fallbacks as defense in depth). 7 weeks too late but at least now it's actually fixed. Thanks for the patience.