small(gui): allow queued inputs while waiting

[michaelneale]

one commonly asked for little feature is that while goose is doing something, you can submit the next thing so it does it when it is finished - this does that very trivially (as seen below) where you can type something in, hit enter, and it will run it when it is ready without you having to wait.

[michaelneale]

originally wanted this in CLI, but that requires a WHOLE LOT more work to fit naturally in, the GUI basically is ready for it (as you can type in already - just that enter is ignored previously).

[zanesq]

LGTM, only comment is people might want to edit or cancel it not sure if thats easy to add or follow up with.

[DOsinga]

we also talked about making it possible to send goose course correcting instructions while it is running - we should figure out how we can combine that with this addition /cc @spencrmartin @jackjackbits

[michaelneale]

yeah currently if you type again, it just replaces it. Course correction is pressing stop (as of now) - if we wanted to course correct while running woudl need to know if to queue or interrupt and inject - want to hold this for that @DOsinga or start with this as is? (the decision/classification would be a different/bigger change, but related yes)

[DOsinga]

yeah currently if you type again, it just replaces it. Course correction is pressing stop (as of now) - if we wanted to course correct while running woudl need to know if to queue or interrupt and inject - want to hold this for that @DOsinga or start with this as is? (the decision/classification would be a different/bigger change, but related yes)

I think this PR is strictly better than what we have on main. if we could hear from @spencrmartin on how the UI would evolve if we wanted course correct, we might have something to go on

[jackjackbits]

the course correct is very good, but also requires a message queue to do properly. you want to go back up and potentially edit what’s in the queue (or cancel it). the other interesting thing to explore is the going back in prompt history. claude code allows you to double esc to go back to previous prompts, reselect them, which actually forks the context back to that point. it’s neat.

…

On 15 Aug 2025, at 16:20, Douwe Osinga ***@***.***> wrote: DOsinga left a comment (block/goose#4081) <#4081 (comment)> yeah currently if you type again, it just replaces it. Course correction is pressing stop (as of now) - if we wanted to course correct while running woudl need to know if to queue or interrupt and inject - want to hold this for that @DOsinga <https://github.com/DOsinga> or start with this as is? (the decision/classification would be a different/bigger change, but related yes) I think this PR is strictly better than what we have on main. if we could hear from @spencrmartin <https://github.com/spencrmartin> on how the UI would evolve if we wanted course correct, we might have something to go on — Reply to this email directly, view it on GitHub <#4081 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BSVVFSCPTEKGKOKDDZVIQGL3NXUD7AVCNFSM6AAAAACD3HKVS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOJRGYYTQNJRGA>. You are receiving this because you were mentioned.

[spencrmartin]

Screen.Recording.2025-08-15.at.2.21.41.PM.mov

Messing about -- but I agree, the power of the queued messages is around the multiple in the hopper related tasks and directions to continue within. Took a minute to first pass mock out a queue'd tray which could expand to showcase additional actions like forking etc.

[zanesq]

Also related message history editing #3798

[spencrmartin]

Screen.Recording.2025-08-15.at.2.54.18.PM.mov

Related to course correcting @DOsinga - wondering if we can have some smart text search for message inputs -- when a user types known "halt your work" saying like "wait I didnt mean that" or "stop" we should halt the work and review the message vs add it to the queue. Feels like voice dictation is a good ICP for course correcting effectively with or without keyboards.

I would be very much annoyed if I wrote stop deleting c drive and goose just tossed it in the queue

[spencrmartin]

Ok - getting a bit further here and would love some eyes

Messages added to the queue, users can move messages around - edit delete etc. Each message can be sent while goose is actively responding if the user submits send.

There is some additional check logic to see if it's a message that will stop goose and pause the queue waiting for the next suggestion. (would like to have a list within settings users could add to)

cc @michaelneale @DOsinga @jackjackbits

PR: #4140

Screen.Recording.2025-08-16.at.6.39.14.PM.mov

[michaelneale]

interesting which actually forks the context back to that point. - there was a proposal/poc elsewhere that would support forking of sessions.

Ok this is no longer "small" @spencrmartin so there would need to be some decision as to if the message warrants interruption?
Also - should this be CLI + GUI? (this currently trivial impl is GUI only)

[michaelneale]

ok lets assume we want this on CLI as well as GUI, so the technical requirements expand to:

• Store a queue of upcoming messages to play in to the session in order
• Have a classifier decide if a given message requires interruption of current command (and if so, do that, and then play it -however what should happen with other queued messages in that case?)
• place the core logic in the main goose crate, cli and goose-server/ui can consume it as a client
• cli to have some key based experience for queuing up messages
• ui/desktop to have similar as is shown above (but show a list of messages)
• Have the ability to esc/uparrow to go back to messages, which (I guess?) could be interpreted as stopping the current command, and resetting the session to that state and immediately replaying it?

This is a fair bit, however if we limit it to gui - then an approach like @spencrmartin shows in #4140 could work (I think it doesn't have the session reset however?) - I have merged that one into this branch, thanks @spencrmartin, looks really nice.

@spencrmartin what do you think about how to restore session to earlier input (even editing it as you go) - say you somehow interacted so you picked an old one, and either edited or hit enter, I would think in that case you always want it to interrupt and possibly set the session back to there? (or do we just replay that message?).

Curious on others thoughts if we can push this out quickly in GUI first and if successful look at porting the queue/logic to CLI? (I may be wrong and there isnt really much to re-use between the 2).

[michaelneale]

@spencrmartin feel free to push to this branch BTW if you wanted to (still haven't decided if this is GUI only but can proceed as if it is for now)

[michaelneale]

@spencrmartin there were a bunch of changes to ChatView.tsx like this https://github.com/block/goose/pull/4140/files#diff-fc74236c3842525f5fa9cbaa3bda8a7ec70bf6f0c52ea1124ebfcb019f0a8121L694 - in the PR I am having trouble with, was that intentional as part of a refactor or was goose overly ambitious there?

[spencrmartin]

there were a bunch of changes to ChatView.tsx like

Is this referencing chatinput? Sorry spinnin back up into this space with a coffee rn. I can take a look at cherrypicking chatinput a bit better.

what do you think about how to restore session to earlier input (even editing it as you go) - say you somehow interacted so you picked an old one, and either edited or hit enter, I would think in that case you always want it to interrupt and possibly set the session back to there?

Not sure I follow gonna try and get thoughts down- editing previously submitted prompts imo should have two actions, overwrite and continue or fork/offshoot. The magic will be in handling the latter with our current multiwindow problem. A different hour problem

I'd really love to consider we consider users engaging with forks and offshoots as being engagements across a canvas > ctas and toggles.

[michaelneale]

@spencrmartin yeah sorry ChatInput.tsx (looks like lots of conflicts now any way so may have to turn this back to an issue and start again, which is ok).

editing previously submitted prompts imo should have two actions, overwrite and continue or fork/offshoot

yes exactly

[spencrmartin]

@michaelneale lemme add it to my morning docket, I think I know where it went wrong and can get it back to standard. The additional elements are additive so feel like it could course correct easily.

[michaelneale]

@spencrmartin cheers - feel free to push over this one (or make a new PR if that makes it easier) - whatever works (I will keep an eye on this one). For now I think the rules based things you have are great and ig it works and plays on top of goose nicely, we can go with this. The more I dig into making it a core thing, the more it ends up complicating goose-server/api a lot for something that is really a front end specific issue (mostly... sort of!)

[spencrmartin]

Cherry picked into this pr @michaelneale #4179

[michaelneale]

retiring this one as migrated over to: #4081