HashiCorp Founder Writes a New Terminal Protocol: Stop Guessing What Your Agents Are Doing

The shared pain of everyone running 8 agents at once

If your workflow is "5 terminal windows, one coding agent each," you know this scene: you switch back to a window and find the agent stopped 20 minutes ago — waiting on a permission approval; another shows "done" but you don't know when it finished; a third looks busy spewing logs but is actually retry-looping the same failed command. The time you spend "checking what each agent is doing" is approaching the time you spend coding.

On October 6, Mitchell Hashimoto — HashiCorp co-founder and author of the Ghostty terminal emulator — published a new specification on his personal blog aimed squarely at this problem: OSC 7501, the Program Status Protocol. In one line: let any program proactively tell the terminal "what state I'm in and why" via a terminal escape sequence — instead of making the terminal (or you) guess.

What OSC 7501 is, in five lines of code

Technically it's a new terminal escape sequence. When a program wants to report status, it sends this to its own pty:

ESC ] 7501 ; state=blocked:kind=permission:app=terraform:msg=... ESC \

The body is a colon-separated list of key=value pairs; the only required key is state, one of five values: idle (at rest, awaiting instructions), working (running, may carry a progress percentage), done (finished, result unseen), blocked (stuck), error (failed). A blocked state also carries kind (permission / question / auth) and a base64-encoded msg explaining why — e.g. Terraform reporting "blocked before apply: 3 to add, 1 to change, 0 to destroy, awaiting confirmation."

Programs running several things at once can report multiple records with hierarchical ids: a deploy tool can be "working" at the root while us-east pushes an image at 40% and eu-west is "blocked" awaiting production-deploy approval. The terminal decides how to render it: a notification, an inbox, a status icon — its choice. A clear state removes records.

Mitchell also published a complete shell-script integration — wrapping rsync with status reporting in plain POSIX sh, under ten lines, no SDK, no sockets, no env vars, no JSON. That example distills the whole design philosophy: emitting status should be as cheap as echo.

Why a new protocol: because today everything is guesswork

Mitchell devotes an entire section to "why existing approaches aren't good enough" — and it's the section vibe coders will feel most deeply.

The backdrop: more and more people run many long-lived agents — background research, issue monitoring, bug fixing, big features — each working a while, then stopping: needing permission, asking a question, or reporting completion. That spawned a new tool category Mitchell calls the "agentic inbox": one view across every running agent — who's working, who's done, who's waiting on you. His named examples: Herdr, cmux, Agent Deck, "and hundreds more."

These tools solve the agent-status problem in exactly two ways today. Way one: heuristic guessing. Read screen contents or window titles, match against regexes of known patterns. Herdr is the honor student here, and admirably honest in its docs: its detection rules are TOML files, with a whole set just for Claude Code — e.g. "window title starting with a Braille spinner character means working." Mitchell points out a brutal fact: the Claude Code detection file alone changed 10 times in three months — because Claude Code 2.1.228 swapped the spinner from Braille to half-circle characters and the rules broke. "This isn't a criticism of Herdr. They're doing the best possible job with the tools available. But it demonstrates well the benefit a unified protocol would have."

Way two: proprietary per-inbox APIs. Programs report state through an inbox-specific out-of-band API, like Herdr's socket API or cmux notify. Better than guessing in some ways — "the program that actually knows its state is the one reporting it." But every program must integrate with every inbox separately (an N×M integration hell), and a local socket doesn't cross SSH or run inside containers without extra bridging. The pty already crosses all of that — your agent on a remote server, in a container, inside tmux, the pty is there.

So OSC 7501's design constraints are crisp: terminal-native, no SDK, no bias toward any GUI presentation, no bias toward any workload (AI included). "Well-behaved terminals ignore unknown OSCs," so old terminals won't break on the new sequence — degradation is safe.

What's already real: not just a paper spec

This isn't armchair speculation. He has implemented it twice himself: once in libghostty (Ghostty's core library), once in Rex (his new terminal project). More aggressively, he built proofs-of-concept for Terraform, Claude Code, Codex, and Homebrew — each as a plugin or fork, none more than a dozen lines.

What does "a dozen lines" mean? Any agent-tool author can make their tool "speak" in an afternoon. And once terminal emulators (Ghostty, WezTerm, Kitty, Alacritty…) follow, users get it with nothing to install. He says he's already in contact with maintainers of many popular terminal programs and emulators who helped review the spec, is collecting feedback, and invites anyone who implements it to email him for a place on the implementers list.

The spec grew out of two lines of his work: Ghostty (the terminal emulator) and Superlogical (his new company building a server-side terminal multiplexer that claims to fix tmux being slow and state-sync being heavy). Both converge on one judgment: the terminal is the common denominator of developers, agents, tools, and infrastructure — what's missing isn't a faster terminal but a "task state" primitive.

Whose shoulders it stands on

OSC 7501 isn't the first escape sequence to attempt "program status" — and the lineage is worth knowing, because it shows what Mitchell solved that others didn't.

The oldest are OSC 9 / OSC 99: the taskbar-progress notifications Windows Terminal supports; programs can report a progress bar. But they express only "progress" — not "stuck, and why."

The most widely used is shell integration (the OSC 633 / 133 family): VS Code and WezTerm use it; the shell tells the terminal via escape sequences "prompt starts here, command starts here, command ended, exit code was X." It solves "where the command line is," but at shell granularity — an agent running 40 minutes inside one command, pausing three times for permissions, is invisible to OSC 133.

Then there's a pile of terminal-proprietary ones: iTerm2 has its own sequences for badges, notifications, progress — every terminal with its own dialect, every program adapting to N of them. Mitchell's ambition: a "terminal-native, vendor-neutral" version where programs emit one sequence every terminal understands. The positioning rhymes with Unicode unifying the encoding zoo — not the most features, but universal.

OSC 7501 complements rather than replaces them: OSC 133 tells you "where the command is," OSC 7501 tells you "how the task is doing." One handles position, the other state. Terminal emulators will most likely implement both — position is for humans to see; state is for machines and humans together.

Our take: agent infrastructure takes a terminal-level remedial class

Place OSC 7501 on 2026's agent-infrastructure map and it fills a long-missing tile. The upper layers exist: MCP lets agents call tools, agent protocols let agents collaborate, inbox tools let humans survey agents. But the bottom layer — how a program reports "how I'm doing" to "where I run" — still relies on 1970s exit codes and log streams. Exit codes speak once, at the end; logs are written for humans, not machines. OSC 7501 is the first serious design of a machine-readable, terminal-native channel for in-flight state.

The direct impact on vibe coders comes in three horizons. Short term (now): if you use multi-agent managers like Herdr or cmux, keep using them — they're this protocol's first beneficiaries; once it spreads, their detection flips from "regex guessing" to "precise knowing" and false positives collapse. Medium term (months): watch whether your agent tools (Claude Code, Codex, OpenCode…) adopt status reporting — adopters will make your multi-agent cockpit an order of magnitude better. Long term: "programs report status" may become as basic as "programs write logs" — the way every CLI eventually learned --help.

One more angle worth savoring: Mitchell wrote an explicit "don't care about AI? skip this section." The protocol is fully generic — builds, deploys, data pipelines, any long task. He didn't package it as an "AI protocol" to ride the hype; he insisted on "terminal-native, generic spec." The best infrastructure is like that: it solves one concrete, painful problem (agent state) but is designed for everyone to use. That restraint is exactly why it might live long.

A final suggestion for the hands-on: Mitchell is openly soliciting implementers. If you maintain a CLI tool or an agent-related open-source project, spend an afternoon adding status reporting per the spec, then email him — your name lands on the protocol's implementers list. Early seats at a standard's table don't come around often in infrastructure.