Repository navigation
TUI: pending permission/question prompts lost after detach + reattach, wedging the session #36604
Description
Description
If you detach the TUI while a permission prompt or interactive question is pending — or one is raised while you're detached — re-attaching leaves the session stuck. The agent is still blocked server-side waiting for a reply, but no prompt is shown and the input looks idle, so there's no way to answer. The only escape is forking the session, which discards the in-flight run.
The cause is that pending permission/question state is transient server memory (a Deferred the tool awaits), announced with a single permission.asked/question.asked event at ask time. The event stream doesn't replay pending state to a client that connects afterwards, and the TUI's bootstrap() hydrates everything on connect except these two stores — so a client that missed the live event never learns about the prompt.
Steps to reproduce
- Start a run that will trigger a permission prompt (e.g. an
edit/bashon ask), or one that uses thequestiontool. - Detach the TUI before answering (or detach, then let a subagent raise a prompt).
- Re-attach to the session.
- The session sits idle with no prompt; the agent is blocked and only forking recovers it.
Operating System
macOS
Activity
github-actions commentedon Jul 13, 2026
This issue might be a duplicate of existing issues. Please check:
Mykhol commentedon Jul 13, 2026
I've raised a PR with a focussed change to resolve this
Fix ExitPlanMode approval bridge
khalilgharbaoui commentedon Aug 19, 2026
Adding evidence for a case that may be broader than the detach/reattach framing here: on my machine the
questionform does not render even when the TUI was attached the whole time, so there is no missed live event to replay. If you consider that a separate bug I am happy to file it separately, but the root cause you describe (pending question state is transient and only announced once) fits what I see, so I would rather add data here first. Noting that #36603 is closed unmerged.Still reproducing on 1.18.18, most recently today (2026-08-19).
The server path is fine; only the TUI render is missing. A
--pure(no plugins) headlessopencode servedrives the whole flow green: the tool blocks,question.askedpublishes,GET /questionlists the pending question, andPOST /question/{id}/reply {"answers":[["Alpha"]]}completes the tool with the answer and emitsquestion.replied. Everything the client needs is exposed and working.Not provider- or plugin-specific.
github-copilot/gpt-5.5, a native provider, fails identically:Tool execution aborted,metadata.interrupted: true, ~27s.The regression brackets to v1.14.24…v1.15.5. From
~/.local/share/opencode/opencode.db,questiontool parts by day and status:The single
completedafter that boundary is the headlessPOST /question/{id}/replytest above, i.e. not a TUI render. Every TUI-driven one since 2026-05-18 endsTool execution abortedwithmetadata.interrupted: true, after 8s to 5300s depending on how long I waited before giving up. The only escape is interrupting.Worth distinguishing from a healthy failure:
The user dismissed this questionmeans the form did render and the operator declined. That is not this. This is silence, then an abort.Happy to run anything specific against a build if it helps.
neriousy commentedon Oct 19, 2026
In v2, reattaching the TUI fetches pending permission requests and question forms from the server, including requests from subagents, so prompts no longer depend only on receiving the original live event. To get v2:
npm i -g @opencode/cli@latestorcurl -fsSL https://opencode.ai/v2/install | bash(desktop: update the app). If you still see this on v2, please open a new issue with the details.