The BSDs have had a version of this for many, many years. If you hit ^T on the terminal, you deliver a SIGINFO to the application you're waiting for. By default, you get the program name, what its blocked on, and info about real/user/sys time and memory use.

Starting an emacs window in the fg:

% emacs ^T load: 0.32 cmd: emacs-31.1 64938 [select] 2.89r 0.75u 0.06s 6% 122404k

I like the idea, but we already have the terminal bell. In my setup, when an agent is done or needs something, it emits a bell. Based on config, this results in a desktop notification if I’m not in the terminal, or a toast from my multiplexer if I’m in the terminal. The terminal pane gets a colored “bell” icon in its title that is cleared when I attach to it.

The total lack of mention of the terminal bell in the article is weird. I think it needs to be addressed for the protocol to be taken seriously. More granular info sounds nice, but also nice is the simplicity of the bell.

Did you read the section on "Relationship to other sequences?"

https://www.superlogical.com/rex/docs/build/program-status#r...

Also - definitely a mention of the terminal bell on https://www.superlogical.com/rex/docs/automate/shell-scripti...

  rex events -s work --json |
  jq -r 'select(.payload.event.payload.name == "bell")
         | .payload.event.payload.block_id'

Cool, so the answer to "we already have bell" is a jq one-liner filtering on a JSON event stream. Now I've got a bell, a new escape sequence, and a daemon to babysit. Good luck debugging that at 3am.

The bell works until you've got six agents going. Then every ding means the same thing and you still have to go look. We had this with CI alerts: one channel for everything, and people muted it within a week. Done vs. blocked vs. failed needs to be distinguishable without attaching.

I've been using a poor mans version of this for decades.

My iTerm2 is configured to show activity, new-output and visual bell in the tab. On Linux I have an approximation for WezTerm.

I have a bell command that I can use in a pipeline or sequence to produce the bell on events I'm interested in. Trivial case is when a program finishes.

I have a fancy alias that can be used in a shell command sequence and which produces different sounds depending on the exit status of the preceding command in addition to sending the terminal bell.

Cool to see this, I've been toying around with custom notification OSCs through zellij and ghostty.

Totally going to extend this for myself with a custom key that encodes a reverse route on each hop so I can easily jump to the window/tab/pane that emitted it, or send back custom actions into a given pane like a permission approve/deny.

The spec’s at https://www.superlogical.com/rex/docs/build/program-status

Innovations like this make me sad that terminfo seems to have died and/or quagmired. It makes detection of these features unscalable and/or impossible, because most of the neoterms are just lying in $TERM, and any value that wouldn't be a lie is missing data in terminfo.

I've also never really fully understood why terminfo seems to be a singular package, and not something like man pages where, e.g., each terminal drops in their respectively entry.

I don't see how terminfo matters for this protocol. An app can emit the escape sequences unconditionally, and if the terminal doesn't support it, it will ignore them. Graceful degradation at its best.

For fire-and-forget output, mostly agreed. As far as I know, though, "ignored if unsupported" holds for well-behaved parsers following the ECMA-48 string grammar, and some older or minimal terminals have leaked OSC payloads onto the screen. Multiplexers also eat or rewrite them unless passthrough is on. Detection only matters if the app wants a reply.

I'm starting to lean in the opposite direction and feel like we should have probably stopped at ecma-48. piling up extension after extension is just straying further from the light.

I just found out about this an hour ago while browsing the Pi docs. I'm really excited to use this as an alternative to the herdr pi extension as I prefer minimizing the number of extensions I have. Also, this could be great to use with a CI tracker (though I'd need one that works with Forgejo).

https://pi.dev/docs/latest/terminal-setup#program-status

Brings back to mind the old IBM 3270 terminal status line (everything old is new again :). Actually think this is quite a good idea.

> Actually think this is quite a good idea.

That's what I thought in the beginning. Once I read the spec to the end, it's clear to me that it's overly specific to one use-case — TUI AI agents.

E.g. `kind := permission | question | auth` doesn't make much sense anywhere outside of that use case. The list goes on...

I also found comms around it super muddy, AI agent use case is mentioned but deceivingly watered down with other use-cases.

Overall, that spec is no where close to Kitty/Kovid's level. It's super sad, since mitchellh's work is usually super high quality.

I hope the community will push back and the spec will get better.

The 3270 comparison is apt, but the OIA was drawn by the terminal itself: the "X SYSTEM" and keyboard-locked indicators lived outside the 80x24 data area. The host couldn't scribble over it with ordinary output. OSC 7501 shares the same stream as everything else, so a stray cat of a hostile file can spoof it.

It's a product of the scope limited interface granted to agents. They get a terminal stream so everything goes into the stream. Piling on more in-band signaling is just going to become a security nightmare. It would be better to have a safe way to query process state that can be locked down as needed.

I absolutely love this and hope it takes off. I've worked on several products with embedded terminals and reliably understanding when they were waiting for human input was such a pain.

How does this compare to setting the status line on a terminal that supports one?

There is another out-of-band way to handle this that a terminal host could implement (no OSC required)

- detect animation in the terminal (defined as changes without user input)

- when the animation stops it needs attention

- if it doesn't have the user's attention, ring some sort of bell

I built such a terminal specifically because this problem was driving me nuts. The marketing for it isn't finished yet (planning to launch next week) but it's been my daily-driver for months if you want to try it out: https://dormouse.sh/

But OSC 7501 seems like a great idea, I'll track its implementation here: https://github.com/diffplug/dormouse/issues/1079

I second this. Herdr is too clunky but it’s the best we have right now.

My first brush with CI, I ended up putting an option to play a sound at the end of local builds because I’d already noticed evidence of Hofstadter’s Law applying to build automation.

The thing is when you expect a task to take five minutes, you don’t watch it, you find something else you expect to take five minutes and do that instead. When that ends up taking ten minutes, or when you remember what you were doing before you started, you finally come back around ten minutes later to find that either the task completed four minutes ago, or it failed after ten seconds and you’ve wasted ten now.

The audio was the best out of band notification I had at my disposal 20 years ago.

My first thought when reading this was actually terminal multiplexing however, like screen or tmux. But I’m also always doing the terminal dance because I work on 4 FOSS projects and I keep 1+ terminal open per project so I can jump in and do bug fixes or pull PRs I’ve landed.

this would be cool to proxy into systemd's new systemd-appd metadata. https://www.phoronix.com/news/systemd-appd

I disagree that this needs a new escape sequence. Bell, SIGINFO, and title changes already cover "done" and "needs input." What's missing is structured progress, and that's per-app. Every terminal will implement half of it differently, and most programs won't emit it anyway. Who's the first adopter besides agent CLIs?