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)
Bug
When
piis installed via Nix (e.g.pkgs.pi-coding-agentfrom nixpkgs), taskplane fails to spawn worker agents with:Tasks fail immediately — not because of the task content, but because the Pi CLI cannot be located.
Root cause
resolvePiCliPath()inpath-resolver.tsresolves the Pi CLI by checking npm global roots and static paths (Homebrew, system Node, Windows APPDATA). None of these cover Nix, wherepilives 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— soprocess.argv[1]is exactly the pathresolvePiCliPath()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 toresolvePiCliPath().A PR with the fix is open: https://github.com/HenryLach/taskplane/pull/new/fix/nix-pi-cli-resolution
Environment
pkgs.pi-coding-agentfrom nixpkgs (nix-darwin + home-manager)/nix/store/<hash>-pi-coding-agent-<ver>/bin/pi~/.pi/agent/npm)