Pi agent registration fully lost in long-running pane (agent_not_found)

[formyideal]

Is this a reproducible bug?

• I confirm this is a reproducible bug, not a feature request, idea, question, contribution proposal, or direction check.

Current behavior

A long-running Pi pane silently loses its agent registration entirely:

• herdr agent list no longer includes the pane at all (another agent pane — opencode — is still listed correctly)
• herdr list shows the pane with no agent tag (earlier the same day it correctly showed (current, pi, working))
• herdr agent explain w6:p1 --json returns:

{"error":{"code":"agent_not_found","message":"agent target w6:p1 not found"}}

• The Pi TUI itself keeps running normally the whole time — only Herdr's view of it is affected
• herdr integration status reports pi: current (v8) (C:\Users\<user>\.pi\agent\extensions\herdr-agent-state.ts) before and after the loss

Expected behavior

The pane should keep reporting idle / working / blocked for as long as the Pi session lives, or automatically re-bind after whatever event dropped the registration.

Reproduction

No minimal repro yet — this happened organically in a long-lived session (many hours, hundreds of tool calls):

1. Start Pi inside a Herdr pane (Windows 11, PowerShell host)
2. Use the session heavily across many hours (see Environment for the extension-heavy setup)
3. At some point the pane vanishes from herdr agent list; herdr agent explain <pane> returns agent_not_found

Suspected contributing factors (unconfirmed, offered as leads):

• The session runs @cortexkit/pi-magic-context, which periodically compacts/materializes session history — possibly emitting lifecycle events similar to the /reload re-anchor case in Pi integration - wrong status #1441
• Several pi install operations added new packages under ~/.pi/agent/npm during the same day (extensions load on restart, so probably unrelated, but noting for completeness)
• A daemon-side state reset combined with the extension not re-binding afterwards would match the "reports silently dropped" mechanism described in Pi use /new session in same herdr pane, the agent status is idle #1377 — but unlike Pi agent status stays idle after typing /new in existing tab #1231/Pi use /new session in same herdr pane, the agent status is idle #1377 (status frozen at idle), here the registration is gone completely

Impact

herdr agent list, herdr wait_agent, and any event-driven supervision silently lose track of long-running Pi panes — precisely the multi-agent supervision use case Herdr is designed for.

Workaround

Quit and relaunch Pi in the pane. The quit sends release_agent, and the fresh start re-binds cleanly (verified pattern from #1377).

Environment

• Herdr version: 0.8.2-preview.2026-08-19-b5c4a0176e91 (preview channel; checked master commits after this build — none touch the pi integration or agent-state registration)
• Update channel: preview
• Operating system: Windows 11
• Terminal: Windows Terminal (pane host), PowerShell
• Agent CLI: pi 0.84.3
• pi integration: v8, current
• Installed pi packages: @cortexkit/pi-magic-context, pi-agents-team, pi-peer, pi-rlm, @weshipwork/pi-herdr, pi-web-access, pi-mcp-adapter, pi-list-skills, @gotgenes/pi-permission-system, pi-rewind

Related issues

#1049 (fixed in v0.7.2), #1231 / #1377 (fixed via PR #1189), #1441 — all involve stale/frozen status; this report is full registration loss (agent_not_found), which I believe has not been reported yet.

[rszrszrsz]

I encountered the same registration-loss symptom on Herdr 0.8.2 stable (9eb52145) on macOS Apple Silicon, with a long-running AGY (Antigravity CLI) pane.

The pane had an explicitly assigned managed agent name. That name disappeared from name-based lookup with agent_not_found, while the AGY (Antigravity CLI) process remained alive in the same pane and continued accepting work and sending replies. Herdr was not restarted during the incident. Renaming the live pane back to the same agent name restored name-based resolution.

So this does not appear limited to Pi on Windows or to relaunch/reload behavior. I have retained the incident evidence and can provide a bounded log or environment detail if useful.