TUI or not TUI - future of goose-cli crate

[michaelneale]

Have been discussing and exploring with @DOsinga and @tlongwell-block about a text-ui for goose, as goose-cli is "old" now (well, almost a year):

#5831 is a demo implementation, some starter discussion questions:

• do we want TUI at all - is it a passing fashion?
• do it in rust, or bring along another dependency if people want cli
• update cli crate in place, keep it as non tui shell (however that is defined)
• if TUI, implement it in rust or use a ts package (delivered via NPM) perhaps as a layer on top of ACP/goose-server
• move to the @goose terminal enhancement and deprecate goose-cli crate (!), making embedded terminal experience the main CLI

[greggyb]

I'll say please do not move to an embedded terminal. One of the nice things about goose is that I can use it where I want. I like my editor (emacs). It has a terminal emulator. I can trivially use goose right in the context where I am already programming. Almost all of the outputs from goose are things I'd like to interact with in my editing environment.

I also like how much I can do from the CLI (though I'd like to see more). Goose is the easiest LLM harness I've found to integrate into my existing environment. I can fully integrate project management where I already manage my projects. I can launch goose with different profiles depending on the project I've loaded. E.g., I can decide to launch the process with a different LLM depending on workload and language, based on project metadata I've already got.

Additionally, I can read the last tool call(s) from the terminal buffer and open the edited files in a new buffer.

I've got lots of small workflow enhancements that are only possible because I can use goose in emacs.

Heavier TUIs make this harder to do. I like that Goose is pretty much a linear chat history, and that I can easily interrogate the state of Goose and sessions from non-interactive CLI commands.

Please keep this around and only implement any TUI enhancements as a shell on top of functionality that lives in the CLI and existing minimal TUI.

[tlongwell-block]

To add to the goose use modes, I primarily use goose:

• autonomous with supervision (working through problems with occasional input from me)
• autonomous without supervision (as part of CI processes or other independent tasks I only see the ultimate output of)

So, the TUI mockup I put together handles both of these better or equally well vs the cli version of goose because that's where I spend all my time.

wrt integration with an editor, I think something like ACP is probably the right solution. The TUI, unlike the CLI, runs a real goose-server and would support ACP. Using an agent scaffold inside a terminal emulator inside of an editor inside of a terminal emulator does seem like a bit of a niche use case.

To be honest, I love the simplicity of the cli, but the ux does leave a bit to be desired. I wouldn't hate to support "cli-mode" from a unified cli/tui interface that uses goose-server as a backend, though. Lower maintenance than (cli + with its own backend) + (electron ui/TUI with a shared goose-server backend)

[justyn]

If the TUI is truly a frontend client implementing just those features specific to the terminal, and other clients like the desktop are the same, then it opens the door to multiple clients connected to the same session.

Not only can different takes on a TUI (like Toad) be easily experimented with but users can even switch between them during the same session.

This would allow native functionality like that provided by Happy Coder, jumping between CLI/Desktop and phone while on the move, and/or switching to a voice agent frontend to continue discussion or monitoring of progress...

[DOsinga]

This to me seems like the way - having the goose server run and then have N clients that all speak the same language. Some of them might connect to the same sessions (like goose mobile /cc @michaelneale ) some might not (ACP) but sometimes it might be useful to open the desktop to look at an ACP session. But maybe also radically different clients like a vibe coded travel advisor that is just a local html file inside an electron thing but still connects to the goose server. If you squint enough this could be connected to MCP-UI even

[tlongwell-block]

Yes, agree. The TUI and the Desktop Electron app use the same goose-server API, which other clients could use just as easily

The only thing goose-server is missing atm is hooks to let connected clients know when there's a new message in the session from a different client. Without that, clients will need to poll.

[DOsinga]

#5182 has an implementation for that - basically allows you to connect to an existing streaing session returning the same protocol

[michaelneale]

yes, goose mobile connects to goosed directly (this worked well as had to be http/streaming, and it was natively that), for that specific case one could argue eventually ACP over http may fit the bill as well (but at the time wasn't ready for that)

[michaelneale]

@greggyb interesting and thanks for writing up thoughts, I think I get what you mean. I would kind of view TUI as a drop in for what you get with goose session today, but perhaps that is not quite right like you point out (but could be). And I love that you use it in emacs too. I think that helps clarify things.

In the next release there is native terminal integration:

eval "$(goose term init zsh)"

which will let you do:

and similar, which means you stay in terminal flow (your real terminal, not a faux one) and goose tracks what is going on in the background (ie commands you run). This may or may not air in emacs flow (may not be needed if you already have a separate native terminal/emacs terminal flow you like which should stay as well).

In some ways a TUI feels a little retro (I love synthwave retro, still not sure about TUIs, which may try to do too much when you already have native workflows that should just work, which I hope the new goose term feature helps with as well).

Like tyler shows, we don't have to make things all TUI all the time.

I would be interested if there are any emerging TUI clients. I saw this: https://github.com/iOfficeAI/AionUi which is a generic (well potentially) ACP GUI client, if there was a TUI client that talked ACP (there isn't last I looked) is one way to have many front ends.

but to your point @greggyb, I think having a compact way that neatly embeds in terminals and things like emacs is a thing we want to keep one way or another.

[tlongwell-block]

I think making ACP the interface to goose will be limiting unless we make goose's primary use case to simply be a backend used by editors and other UIs

goose has lots to offer as the primary interface that would be cumbersome to expose over acp. Being able to switch models and providers on the fly, rich session management and forking, a (potentially) powerful set of macros, and more.

goose, as the best open source agent out there, should be doing its best to push forward the standard in terms of UI/UX, not just the backend.

@greggyb right now the TUI does accept stdin and recipes for headless execution (using the same goose-server backend). And, yes, exposing configuration management via a simple cli interface makes a lot of sense. However, for scripting, there's no reason you can't edit the goose config file directly. It's yaml and available to you.

[DOsinga]

ACP is great, but yeah, I think it is too limited for all interactions - trying to make recipes for example work on top of it seems like a stretch.

[michaelneale]

is it reasonable to think of ACP as a layer on goose-server/goosed (or goosed protocol a logical superset?)

[greggyb]

As long as headless execution includes the same sort of thing I can introspect from the CLI.

Using the same working example I've been in all of my comments (example only, not an exclusive list of desired functionality): if I can do goose-tui -e '/list-sessions' and the output is the same (or substantially similar, and easy to pipe around and manipulate with other standard CLI tools) as goose session list from the current CLI, then I'm happy.

Similarly, if I need to do something like goose-tui -e '/session <session-id>; /export-session' instead of goose session export --session-id <session-id>, then that's fine.

I just don't want to land in a situation where I cannot introspect persistent state without launching an interactive UI, or where I have to build an application on top of goose's state database and then have to worry about keeping that up to date with Goose releases.

As for launch configuration, I do not think it is reasonable to suggest editing the config file as an alternative to env variables. For one, it introduces a data race; this should be a sufficient reason to not accept it as the recommended method for modifying launch parameter. Beyond that, it's simply clunky and a regression in functionality from the current offering.

IF it is decided that env vars are going away for some reason, then there must be an arg or env var to point to a specific configuration file for that process being launched.

[tlongwell-block]

Oh, not at all what I meant. Should have been more clear there. I love env vars for config, though @DOsinga might disagree ;)

I'm hoping at some point to put in a PR to move goose to a more normal config setup where cli args, env vars, and the config file can all specify all config (in that order of precedence) just like most modern production applications.

[michaelneale]

@codefromthecrypt just pointed this out to me https://willmcgugan.github.io/announcing-toad/ - so there is some signal there may be a future TUI client for any agent (presumably using ACP or similar)

[codefromthecrypt]

I like being able to eventually shed weight and not limit folks.

I have been messing with neovim+avante for ACP and while I haven't seen an Emacs I do think ACP has legs and not just rich UIs but TUI would be drop in over time. I think this is more than a dream like I do think this will work for most use cases.

Goose terminal and its bare CLI can still be useful even if there are distributions of goose that bundle it with a TUI or the TUI loads goose.

I think many agents have a CLI even when embedded in an IDE just to do config and sign on stuff.

TL;DR; would love to see more work to get goose ACP parity with the claude adapter, which would open up many more frontends. Meanwhile we can keep the existing TUI as long as we can afford it, and encourage cool other terminal goodness.

[peterwilli]

I side with Greggyb that Goose is in a very specific niche and does a very good job at it. I also integrated Goose all into my work life, and it is working better than anything before! For example, in Helix editor I added special macros to select parts of my source code and put it in the context. Together with #5823, this is now my daily driver!

TUIs are IMO great until they ain't. For example, I came from Crush, and it has a stunningly sexy UI, but once I found even simple things as copy pasting don't work, it just becomes so hard to workaround, whereas now I can simply change the pipeline in my editor of choice.

I do think however choice is important and if the TUI is a separated crate that can be maintained (i.e. having goose-cli and goose-tui) making sure that there's a clear distinction can be a good idea.

[tlongwell-block]

I think there's enough common machinery required that combining the CLI and TUI can make sense. The CLI should eventually move to using goose-server as the backend, anyway, just like the Desktop app and the draft TUI

Being able to do something like ./goose-tui --cli works out well implementation wise because there's so much that should be shared. (I've got a demo of this already in #5831)

[peterwilli]

Is there an advantage for combining these rather than having separate binaries (goose-cli, and goose-tui) and share libraries/crates instead? Asking out of curiosity, I'm not to familiar yet with the source code to know for sure.

[michaelneale]

mostly convenience, if there are multiple crates, there is always a (small) risk things get accidentally duplicated. ie there are some things when we look now which are duplicated in goose-server vs cli, or end up in cli first when they should have been in core (eg ACP - my fault!) as sometimes isnt' clear, so really just trying to keep it simple/clean (especially for goose itself so it doesn't have to wait for direction from a human of what crate to put things in).