feat: add /back option to shell command confirmation prompt

Resolved 💬 6 comments Opened Apr 17, 2025 by b05505027 Closed Apr 21, 2025
💡 Likely answer: A maintainer (tibo-openai, collaborator) responded on this thread — see the highlighted reply below.

Hi,

Currently, when the model tries to run a shell command, it asks the user with choices like:

  Yes (y)
  Yes, always approve this exact command for this session (a)
  Edit or give feedback (e)
  No, and keep going (n)
  No, and stop for now (esc)

But if a user accidentally selects the wrong option—say they hit Edit or give feedback instead of Yes, always approve this exact command for this session—there’s no way to go back and choose again.

I’d like to suggest adding a /back command (or something similar) so users can return to the previous menu. What do you think?

View original on GitHub ↗

6 Comments

3xpl0itk1t · 1 year ago

Picking This

tibo-openai collaborator · 1 year ago

Would this undo the edit? Also, some commands cannot be undone, how do you suggest to handle this?

b05505027 · 1 year ago

@tibo-openai I may not have explained that clearly. Let me clarify: after you choose the edit option, the CLI pauses and waits for user's input. If you decide you need to return to the previous menu before submitting your feedback or executing the command, just type /back to go back to the multiple‑choice section.

So in short /back simply aborts the feedback prompt and returns you to the multiple‑choice menu before any shell command is run. It never reverses an already‑executed command.

Does this answer your question?

3xpl0itk1t · 1 year ago

@tibo-openai Thinking of adding a confirm option for users where they can be prompted to confirm their selection or /back to go back to the terminal command menu

3xpl0itk1t · 1 year ago

@tibo-openai The pr for this feature is ready for review Please look at it Thanks

tibo-openai collaborator · 1 year ago

I've tried this out and I feel that this adds too much friction in order to improve things for the unfortunate < .1% of the times where you might misclick and I don't think that is the right trade-off here. Will close this for now, but thank you for the contribution!