Repository navigation
"upgrade pi and packages" button trow error when pi already exist #15
Description
npm install --global @mariozechner/pi-coding-agent@latest && /usr/local/share/nvm/versions/node/v26.3.0/bin/pi update
vscode ➜ /workspaces/wai $ npm install --global @mariozechner/pi-coding-agent@latest && /usr/local/share/nvm/versions/node/v26.3.0/bin/pi update
npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead
npm warn deprecated @mariozechner/pi-agent-core@0.73.1: please use @earendil-works/pi-agent-core instead going forward
npm warn deprecated @mariozechner/pi-tui@0.73.1: please use @earendil-works/pi-tui instead going forward
npm warn deprecated @mariozechner/pi-ai@0.73.1: please use @earendil-works/pi-ai instead going forward
npm error code EEXIST
npm error path /usr/local/share/nvm/versions/node/v26.3.0/bin/pi
npm error EEXIST: file already exists
npm error File exists: /usr/local/share/nvm/versions/node/v26.3.0/bin/pi
npm error Remove the existing file and try again, or run npm
npm error with --force to overwrite files recklessly.
npm error A complete log of this run can be found in: /home/vscode/.npm/_logs/2026-06-03T22_50_40_904Z-debug-0.log
pi already exists by "feature" item "ghcr.io/RodriBus/devcontainer-features/pi-coding-agent:0" in devcontainer.json
Activity
napa3um commentedon Jun 3, 2026
and why does the button try to install @mariozechner/pi-coding-agent and not @earendil-works/pi-coding-agent? 🤔
napa3um commentedon Jun 3, 2026
Hmenez3s commentedon Jul 18, 2026
I can reproduce a more severe variant of the same root problem on Windows/NVM: the upgrade action can replace a working Earendil PI installation and make installed extensions crash on the next startup.
Reproduction
@earendil-works/pi-coding-agentwithpi-xai-oauthenabled.pi-vscode0.0.9.pi-xai-oauth, with a missing-module path ending in@earendil-works/pi-ai/dist/index.js/compat.Root cause
src/upgrade.tshardcodes:Therefore the action runs approximately:
This does not upgrade the package that owns the resolved binary when the user installed the maintained Earendil fork. It replaces/mixes package families before
pi updateloads installed packages.The failure is not caused by
compat.jsbeing absent from current Earendil PI:@earendil-works/pi-ai@0.80.10containsdist/compat.jsand exports./compat.@earendil-works/pi-coding-agent@0.80.10aliases@earendil-works/pi-ai/compatin its extension loader.pi-xai-oauth@1.3.6declares peers>=0.80.1 <0.81.0and its official loader check passes against exact PI0.80.10on Node22.19.0.The mixed loader/package family causes the
@earendil-works/pi-ai/compatsubpath to be resolved incorrectly, producing the observed startup crash before package update/recovery can complete.Expected behavior
The extension should discover the package that actually owns the resolved
pibinary and upgrade that same package. At minimum, it should show the package name before confirmation and refuse to replace a different distribution/fork.A robust approach would be:
pipath.package.jsonand readname/version.pi updateonly after the CLI upgrade succeeds.I also verified the recovery approach in a local installer without publishing private repository details.
One additional environment note: current Earendil PI
0.80.10declares Node>=22.19.0; the affected Windows report used Node22.12.0, which should also be upgraded, although it does not explain the hardcoded package replacement.