Summary
There's no local watchdog for a session stuck in streaming/compacting. If the underlying pi process ever wedges a turn without emitting a terminal lifecycle event (agent_end/turn_end) — see earendil-works/pi#7336 for a concrete repro on the pi side — pi-coding-agent--status stays streaming/compacting forever with zero feedback to the user, since it's purely driven by events arriving from the RPC stream.
What happened
I had two chat buffers (different working directories / worktrees of the same repo, same Emacs daemon) both silently stuck for 38 and 44 minutes with no CPU/network activity in the underlying pi process (confirmed via sample/lsof on the OS process). Nothing in the UI indicated anything was wrong beyond the eternal "thinking" state — no timeout, no message, nothing in the *pi-coding-agent-stderr* buffer either.
Running M-x pi-coding-agent-abort (C-c C-k) on each buffer immediately un-wedged both sessions back to idle. So the fix, once you know about it, is trivial — the problem is discovering that you need to do it, especially when the buffer just looks like Pi is still working.
Suggestion
Add a simple local heartbeat/watchdog: if pi-coding-agent--status is streaming or compacting and no new process output/event has been observed for N minutes (configurable, maybe default 3–5 min), surface a message, e.g.:
Pi: no activity for 5 min — session may be stuck. Try C-c C-k to abort.
This doesn't need to auto-abort (that could be surprising/destructive for legitimately long-running turns) — just a visible nudge so the user knows to check, instead of waiting indefinitely without any signal.
There's already a similar concept in the codebase for the idle state (pi-coding-agent--state-needs-verification-p / pi-coding-agent--state-verify-interval, 30s periodic re-verification) — maybe a comparable idle-timer could be reused/extended to cover the busy states too, just checking "time since last process output" instead of "time since last state fetch."
Environment
pi-coding-agent 20260721.810 (ELPA)- Emacs 30.2, macOS
@earendil-works/pi-coding-agent 0.82.1, --mode rpc, :connection-type 'pipe
Happy to provide more diagnostic detail if useful — I have the full session logs from the two stuck instances (see the linked pi-side issue for excerpts).
Summary
There's no local watchdog for a session stuck in
streaming/compacting. If the underlyingpiprocess ever wedges a turn without emitting a terminal lifecycle event (agent_end/turn_end) — see earendil-works/pi#7336 for a concrete repro on thepiside —pi-coding-agent--statusstaysstreaming/compactingforever with zero feedback to the user, since it's purely driven by events arriving from the RPC stream.What happened
I had two chat buffers (different working directories / worktrees of the same repo, same Emacs daemon) both silently stuck for 38 and 44 minutes with no CPU/network activity in the underlying
piprocess (confirmed viasample/lsofon the OS process). Nothing in the UI indicated anything was wrong beyond the eternal "thinking" state — no timeout, no message, nothing in the*pi-coding-agent-stderr*buffer either.Running
M-x pi-coding-agent-abort(C-c C-k) on each buffer immediately un-wedged both sessions back toidle. So the fix, once you know about it, is trivial — the problem is discovering that you need to do it, especially when the buffer just looks like Pi is still working.Suggestion
Add a simple local heartbeat/watchdog: if
pi-coding-agent--statusisstreamingorcompactingand no new process output/event has been observed for N minutes (configurable, maybe default 3–5 min), surface a message, e.g.:This doesn't need to auto-abort (that could be surprising/destructive for legitimately long-running turns) — just a visible nudge so the user knows to check, instead of waiting indefinitely without any signal.
There's already a similar concept in the codebase for the
idlestate (pi-coding-agent--state-needs-verification-p/pi-coding-agent--state-verify-interval, 30s periodic re-verification) — maybe a comparable idle-timer could be reused/extended to cover the busy states too, just checking "time since last process output" instead of "time since last state fetch."Environment
pi-coding-agent20260721.810 (ELPA)@earendil-works/pi-coding-agent0.82.1,--mode rpc,:connection-type 'pipeHappy to provide more diagnostic detail if useful — I have the full session logs from the two stuck instances (see the linked pi-side issue for excerpts).