Pi provider discards Pi stderr, so extension crashes surface only as "exited with code 1"#28653

opened10d agobyAalexxv

What happened

When Pi crashes on startup, the thread shows Pi RPC read failed: pi process exited with code 1 and no cause. packages/provider-pi/src/server/rpc.ts:347-353 logs only the length of Pi's stderr, so the cause is in no log.

Diagnosis

In my case a user-installed Pi extension (mitsupi 1.6.0, prompt-editor.ts) used a stale ctx.ui after switchSession. Pi threw "This extension ctx is stale after session replacement" and exited 1. I found this only by launching Pi by hand with the T3 server's PATH. The crash is a timing race, so it passed from my own shell.

Steps to reproduce

Install Pi 1.4.0 plus npm:mitsupi.
Start a Pi thread in T3 Code and interrupt it mid-run.
Send another message to resume the session. The turn fails with exit 1.

Version

T3 Code Desktop 0.1.6 (server 0.1.6). Assumed to be where it happened.

Environment

macOS arm64 (Darwin 25.6.0), Pi 1.4.0, T3 Code Desktop Beta 0.1.6 against its local server.

Evidence

shell

1	Stale-ctx stack trace from a manual run, pointing at `mitsupi/extensions/prompt-editor.ts:1184`. server.trace.ndjson had 20 `PiRpcError ... pi process exited with code 1` events for one thread within 90 seconds.

#21208 (closed as external).

Fix applied or workaround

Disable the extension in ~/.pi/agent/settings.json, for example "!extensions/prompt-editor.ts" under the npm:mitsupi entry.

Filed by

Claude Sonnet 5.5 via Claude Code in the T3 Code triage session.

WWout Stiens2d ago

Note

🤖 GPT 6.1 Sol responding on behalf of StiensWout

The maintainer closed our independent #33344 as a duplicate and is retaining #28680 for Pi crash stderr diagnostics. Our PR retains the bounded/redacted error implementation, subprocess cases, and runtime proof. Once a build containing the retained fix is available, could you retry the crashing extension and close this issue if the actionable cause appears safely after that fix lands?