Brings back to mind the old IBM 3270 terminal status line (everything old is new again :). Actually think this is quite a good idea.
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.
Let's say I'm upgrading a large software enterprise application. I start the upgrade process. After 5 minutes, the process determines that the upgrade will require an extra 1.5GB of storage and asks me if I would like to continue with the upgrade. After 15 minutes, I'm presented with a username / password prompt to enter credentials to retrieve a package from an external resource needed for the upgrade. After another 5 minutes, the upgrade process has detected that there are a number of derelict files detected and asks for permission to remove these files.
A cli asking for a password is a pretty normal thing, I think?
As a frequent internal tool writer, I’d say it’s a fact of life but an undesirable one. I’m always trying to avoid pausing for credentials in the middle of a run, either by doing them right at the beginning or by using some sort of durable credentials system like ssh keys.
There’s always two people at every company who refuse to set up auth automation though, so you end up handling it. They are very stubborn. Even when it trips them up in front of observers while executing an urgent task, I’ve only occasionally convinced them to agree to set up trust instead of typing a password every single time.
Which is to say, I have to support password prompts even though they drive me up the wall.
Yes, but a CLI can ask for literally anything. We'll end up adding things there and with a zoo of hard-to-support implementation of that _protocol_.
CLI can also _blank_, do we want to support it as well?
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.
As someone who works on a lot of CLI tools at work I actually like the idea of implementing this in some of our long-running tooling, completely independent of the AI agent use case.
I actually created a separate golang library with something like this in mind: https://github.com/danudey/ansipants
The original idea I had being that CI environments, or anywhere that shows terminal output, could use a streaming ANSI parsing library to detect when a program sent a 'change window title' OSC event and then start a new collapsable section in its output. This would let programs update the actual terminal window title with its current state when running locally and update the CI interface when running in CI.
Adding in the ability to specify the program's current status and (optionally) progress could be extremely useful in CI environments as well. Imagine, for example, a long-running analysis task which uses OSC 7501 to say that it's currently running and is 75% of the way done. CI could expose that in the UI to provide useful information to the end-user without having to print a progress bar or multiple progress lines to the fake terminal it's being run in.
Is https://github.com/danudey/ansipants private?
long-running analysis task can use osc9;4 for progress reporting
spec: https://ghostty.org/docs/vt/osc/conemu