Repository navigation
[chore/feature] : Tell OpenCode what to do differently #451
Description
Currently, in the TUI, if we reject a patch, it prompts us to enter a reason; however, in this plugin, it simply interrupts the process. It would be great if we could have a similar experience here
Metadata
Metadata
Assignees
Labels
No labels
Activity
sudo-tee commentedon Jul 8, 2026
Good idea.
I would like to do one QoL refactrore before this. Where you can have an inline input when selecting the "Other" option.
This would fit well in this workflow.
I will have a jab at it and sede if it's possible
disrupted commentedon Jul 8, 2026
sorry for the low effort comment, but I do actually prefer our current behavior. I was recently quite bummed when I used the TUI and didn't find an obvious way to halt the execution completely (circumventing this dialog). is there even a functional difference to cancelling and submitting a new prompt?
jensenojs commentedon Jul 8, 2026
Aha, glad to see you again. However, I'm still curious why this interaction method isn't always present in TUI. It doesn't seem to trigger very stably. But we should always be able to make it optional, right?
sudo-tee commentedon Jul 8, 2026
You can have a look, it is still "floating window" and work just like snacks input or any other plugin that overrides vim.ui.input, it's just inline.
there is an option to opt-out of it.
#455
sudo-tee commentedon Jul 8, 2026
@disrupted
I think I misunderstood your comment.
But yes if we add this interaction we can add an option. We could also support sending an empty reason or even add a
Deny and stopoptiondisrupted commentedon Jul 8, 2026
did you find which API method that would be? I can only see
session.abort({ path })(https://opencode.ai/docs/sdk/#sessions) which doesn't take any extra arguments. if the abort reason would be sent as a followupsession.prompt()anyways, then our current behavior is actually more clear imo. and it allows instantly abortingedit: found it 🤦🏻
postSessionByIdPermissionsByPermissionId({ path, body }). it takes an optionalmessagestring https://github.com/anomalyco/opencode/blob/77429f59823c8c6df9cfee95d4c663043b017f46/packages/sdk/openapi.json#L4952jensenojs commentedon Jul 15, 2026
origin comment now move to diffview issue
sudo-tee commentedon Jul 15, 2026
@jensenojs I think this comment should go in the #318 Better Diffview thread. I have a couple of comments to add to it, but let's keep this thread focused
I don't want to deviate to much, as I am working on the
Tell opencode differently featureI digged a little bit because I was not able to reproduce the behavior at first.
It turns out it's only when answering a permission for a subagent that it would prompt for details about the rejection.
Should we keep the same behavior as the TUI for that specific case ?
Calling the api @disrupted provided works also on the main agent.
Maybe we can have something like this
The reject will just be the regular Reject tha stops the flow in both main agent and subagents.
jensenojs commentedon Jul 15, 2026
agree and ok, doneYes, I did trigger that feature in Subagent at the time; I was a bit puzzled before as to why it wasn't triggering very often
Keeping the default behavior consistent with tui is always the least bad choice, but personally I might configure it so that the main agent can also enjoy it, and using sth like double-press of Esc to explicitly interrupt it, Opencode's restraint on the subagent leaves me feeling a bit helpless and annoyed, even though I understand the reasoning behind it.
@sudo-tee
sudo-tee commentedon Jul 15, 2026
I like the double escape idea instead of 2 Reject option.
sudo-tee commentedon Jul 16, 2026
@jensenojs @disrupted
#471
you can play with the PR and see if this new workflow works for you :)
jensenojs commentedon Jul 16, 2026
I'm feeling a little under the weather, I'll test this feature tomorrow (｡･ω･｡)ﾉ♡