pi-reload-all

Quick reference

• Use it for: Picking up a new suite pin, settings, skills or keybindings in every running Pi at once, instead of /reload pane by pane.
• Enable: Select packages/pi-reload-all/src/index.ts with pi config. Every session that should be reloaded needs it.
• Controls: /reload-all signals this machine and every enabled herdr machine and shows live progress above the editor; /reload-all --local only this machine; /reload-all stop closes the progress view. /reload-when-idle is the command each session runs on itself. No model tool.
• Settings: None. The signal is reload-request in Pi’s agent directory (~/.pi/agent, or PI_CODING_AGENT_DIR).
• Requirements, cost & privacy: Other machines are reached with ssh -o BatchMode=yes <target>, using the targets from herdr machine list, so key-based SSH must already work. No network otherwise, no inference.
• Integrations & limits: Herdr is optional: without it only this machine is signalled. Interactive (TUI) sessions only; print and RPC sessions ignore the signal.

How it works

Nothing is typed into other panes. Typing /reload with herdr agent prompt would append to a half-written draft, and Pi ignores /reload while a turn runs. Instead /reload-all writes a small request file, atomically, on each machine, and every session running this entry watches that file (with a 30-second poll as a fallback) and reloads itself:

1. A request written after the session started shows reload pending in the footer (with pi-status-footer, as its top row).
2. The session waits, rechecking every two seconds, until nothing a reload would break is in progress. The footer names what it waits on (for example reload pending: subagents (2)):
   • a running turn, a queued message, or a draft in the editor;
   • a keystroke anywhere in the terminal within the last five seconds;
   • async subagents or plan-mode planner runs (their herdr:background and herdr:working holds), which a reload would abort; pi-bg jobs and awaited Herdr children survive a reload and do not delay it;
   • an open question or permission dialog, or any open overlay (todo list, pickers);
   • anything that answers the reload-all:probe event with a hold: pi-sidebar does while it is open or replying.
3. It then runs Pi’s own reload, the same as /reload.

The session that ran /reload-all reloads too, once it is safe. Its report, one line per machine with the number of Pi panes Herdr sees there, is kept in the transcript across that reload.

Live progress

Each session that receives a request reports its progress in reload-acks/<request id>/<session id>.json in the agent directory: pending (with what it waits on), reloading, then reloaded (written by the reloaded runtime) or failed. The session that ran /reload-all shows them above its editor, reading this machine’s folder directly and each signalled machine’s over ssh every three seconds, and picks the view up again after its own reload:

reload-all · 7/12 reloaded
  MacBook-Pro  runnable-models  pending: subagents (2)
  NUC          homelab          pending: typing
  MacBook-Pro  pi-plugins       reloaded

(Example output.)

The view closes, leaving its last summary in the transcript, when every session Herdr counted has reloaded or failed; or when everyone who answered is done and nothing changed for 30 seconds (the rest are counted as not answering, for example sessions without this entry or on an older version); or after ten minutes. /reload-all stop closes it early. Report folders older than a day are removed when the next request is written.

Anything else that writes the file triggers the same reload. For example, a package-update script can write it after installing a new pin, so sessions pick the pin up without a manual step.

Limits

• A session that never becomes safe stays pending; the footer says why. Clear the draft or close what is open, or run /reload yourself.
• Only the work listed above is detected. An extension that keeps unsaved in-memory state while Pi is idle, and does not answer reload-all:probe, loses it on reload, exactly as with a manual /reload.
• If Pi is compacting at that moment, Pi skips the reload and the session stays on its old code. Run /reload afterwards.
• A machine that cannot be reached over SSH is reported as failed. Its sessions are not signalled.

Development

The component’s check runs typechecking and a Node test file covering the request file, the remote shell write, freshness by local mtime, the wait for an idle, empty session, and the self-dispatched reload. It does not drive a live TUI.

GitHub source