Pimp My IDE / garage dispatchBack to the garage
October 8, 2026 / terminals / attention routing

Stop scraping the spinner.

OSC 7501 lets a program tell the terminal whether it is working, blocked, done, idle, or broken. That small contract could replace a pile of brittle agent-status guesses.

The program knows its state. Let it report the state.
IdleWorkingBlockedDoneError
BLOCKED / PERMISSIONApprove production deploy?
app=deploy ยท current state, not a guessed screen pattern

The spinner was never an interface.

Long-running terminal programs already move through useful states. They work, wait for input, finish, or fail. Tools that collect several sessions often infer those states from window titles, spinner glyphs, screen text, or program-specific sockets. Mitchell Hashimoto's OSC 7501 proposal gives the program a terminal-native report instead.[1]

The timing matters. Claude Code 2.1.295 added Program Status Protocol support on October 8. Its release notes say compatible terminals can show whether Claude Code is working, waiting on the user, or done.[3] This is one implementation claim from one release. It does not establish broad terminal support.

A status inbox should read declared state before it tries to recognize animated punctuation.

The contract is small enough to inspect.

A report is an Operating System Command sequence with colon-separated key=value pairs. state is required. The defined values are idle, working, done, blocked, error, and clear. A blocked report can name permission, question, or auth as its kind. Working and blocked reports may carry an integer progress value between zero and 100.[2]

The protocol also supports record IDs. A parent task and its children can report separate states in one terminal. Reports replace the addressed record instead of patching old fields. That rule matters. A stale permission message should not survive when the program returns to work.

Lifetime is part of the meaning.

working and blocked disappear when the attached process exits or a new shell prompt begins. done and error can survive those events so the user can find an unseen result. There is no heartbeat. The terminal owns the records and decides how to present them.[2]

That separation is the strongest part of the proposal. A command reports facts. The terminal can use a tab marker, session list, quiet notification, or no visible treatment. A dashboard does not need every command to know its layout.

Structured status is still untrusted input.

A process that controls terminal output can also emit a false status report. The specification treats every field as untrusted. It bans control characters in decoded titles and messages, says terminals must not parse them as markup, caps a whole sequence at 4,096 bytes, and recommends rate limits for sounds or desktop notifications.[2]

A status message should identify the terminal that produced it. It should not become authority to approve a tool call, enter a credential, or claim that a deployment passed. State helps route attention. It is not execution proof.

The rough edge is vocabulary.

The Hacker News thread found the useful disagreement fast. One commenter argued that permission, question, and auth lean too hard toward agent interfaces. Another pointed out that ordinary command-line programs ask for passwords too.[4] That is the right argument to have before more programs depend on the names.

The design below makes the separation visible. One native control chooses the declared state. The app and message fields shape a report preview. The readout says what the state means and what it cannot prove.

Interactive makeover / status selector plus report preview

Wire the signal panel.

This replaces a spinner legend with one native state selector, a machine-readable preview, and a plain-language limit. It does not send an escape sequence or inspect terminal support.

Declare stateEncode messageRender locally

Status detents

Choose what the program knows now. Edit the app and message. The preview updates without writing control bytes to your terminal.

Declared state
Use one to 32 letters, numbers, dots, underscores, plus signs, or hyphens.
Human-readable text is base64 encoded in the protocol. The preview shows that encoded value.
Local readout / declared status

Signal receipt

BLOCKED / PERMISSIONNeeds user action. Cleared at process exit or the next shell prompt.
Attention route requestedThis record can ask the terminal to surface a permission wait. It cannot grant permission or prove that the request is safe.
Sources read / October 8, 2026

Source log

Open the evidence boundary
  1. Mitchell Hashimoto, "A Terminal Protocol for Program Status (OSC 7501)", October 6, 2026. The post explains the motivation, current heuristic approaches, and the intended split between state and presentation.
  2. Program Status Protocol specification, read October 8, 2026. The specification defines syntax, records, state lifetime, feature detection, security rules, limits, and examples.
  3. Claude Code 2.1.295 release notes, released October 8, 2026 at commit 602df92. The release notes state that Claude Code added OSC 7501 support.
  4. Hacker News item 49984159, read October 8, 2026. The discussion surfaced disagreement about the blocked-state vocabulary. It is not evidence of protocol quality or adoption.

Evidence boundary: the specification supports protocol semantics. The author's post supports its motivation. Claude Code release notes support one implementation claim. We generated a blocked example and checked its byte structure through a hex dump. We did not send the sequence to a terminal, test feature detection, or verify a compatible terminal implementation. The signal panel is a local teaching demo.