The open-source agents in earendil-works/pi and charmbracelet/crush have added a shared way to report their status to a terminal. Pi 1.1.0 and Crush 0.98.0, both released on October 8 in Paris, can tell a supporting terminal whether they are working, waiting for a person, finished or stopped by an error. The shared format is the Program Status Protocol, also called OSC 7501.
The useful difference is between a program that is busy and one that cannot continue until you answer it. Someone running several agents in separate tabs should not have to keep opening each conversation to discover a permission request or login prompt. An explicit status message gives the terminal something it can organize across tools, even when their interfaces look different.
That capability has reached the senders’ releases. Receiving it remains a separate choice: support is young, and neither an ordinary terminal nor a multiplexer can be assumed to understand or forward the reports.
The waiting reason travels with the state
Crush’s new mapping puts requests for human help ahead of its busy indicator. An open permission dialog reports a permission wait; an unanswered question reports a question wait; an AWS sign-in dialog reports an authentication wait. Only after checking those conditions does it report the agent as working.
That ordering matters. A running process may be doing no useful work because a person has not approved its next action. The terminal receives both the state and a reason, rather than trying to infer urgency from a spinner or changing window title. Crush uses fixed messages for these waits. Its regression test also checks that returning focus clears the recorded completion or error outcome back to idle.
Pi has a different lifecycle to translate. Its reporter keeps a run active through automatic continuations and announces its outcome when the session settles. Cancelling a run produces idle rather than done. An extension dialog or login can take precedence over ongoing work; context compaction is reported as work, too.
The messages are deliberately smaller than a transcript. Pi sends session names, dialog titles or the first line of an error, rather than forwarding prompts and model answers as status output. That still leaves the application responsible for what those labels contain. Both implementations describe their own lifecycle; a done label says that a run ended, not that its answer is correct.
A terminal feature spreads through a library
This is more than two repositories using similar words. Crush’s October 8 change upgrades Bubble Tea, its terminal interface library, from 2.0.9 to 2.1.0 and supplies the library’s new program-status field. The library implementation emits the sequence when that field changes. Pi implements the same protocol through its own terminal layer.
Bubble Tea’s October 8 release therefore gives other application authors a reusable route to the same signal. It does not make their programs report useful states automatically: each still has to decide what counts as working, waiting and complete.
The proposal is recent. Its revision history starts on September 28; Mitchell Hashimoto brought parser support to Ghostty’s library in an October 6 pull request, explaining the connection to his work on Superlogical. The common format leaves presentation to the receiver. Rex’s documentation describes indicators in its session picker and unfocused tabs, plus events that scripts can react to.
There are useful boundaries around that example. Rex is an invitation-only macOS beta. Ghostty’s library change does not mean the Ghostty application displays the status. TUIOS documents another receiver, but its inspected latest release, dated October 2, predates this work. Current source documentation and an installable release are different evidence.
The same need still has competing answers
Codex offers a timely counterexample to a story of universal agreement. Its October 8 implementation reports idle, working and waiting through iTerm2’s different OSC 21337 format. It explicitly checks for a direct iTerm2 terminal and excludes multiplexers. We established this as merged source, without verifying a containing installed release.
Even with the common format, the path between sender and receiver matters. Pi’s documentation says tmux and screen do not forward its reports. By default, Pi asks whether the receiver supports the protocol before sending state. Forcing it to emit messages does not make an unsupported intermediary carry them.
We checked that both release tags contain the sender changes and ran Pi’s five isolated upstream tests for message formatting and support-reply recognition; all passed. We inspected the broader state-mapping and terminal-negotiation tests, but did not run a mixed Pi-and-Crush session in Rex or TUIOS. Nor is a status report a liveness monitor: a program can report working and then stall.
The gain is a shared way to ask for attention. It moves knowledge the agent interface already has into a place that can show several programs together. The next useful trial is a pinned sender-and-receiver combination that correctly carries a permission wait, a cancellation and a completed run—and clears each indicator at the right moment. That would show whether the common language saves the person another round of opening tabs.