anomalyco / anomalyco/opencode
tui: pending question form lost after client reconnect — unexitable modal (FormNotFoundError loop)
@kommander is already working on this.
Since Aug 23, 2026.
- Dominant language
- TypeScript
- Stars
- 209k
- Forks
- 27.5k
- PR merge metrics
- PR metrics pending
Description
Summary
When the TUI's connection to the shared background service drops while an agent-initiated interactive question form is pending, the server discards the pending form and does not restore it on reconnect. The TUI keeps its stale modal mounted; every subsequent keypress produces a 404 FormNotFoundError unhandled rejection, keyboard input stays trapped in the dead modal, and the terminal must be killed to recover.
Environment
- opencode version: opencode2 v0.0.0-beta-17963 (channel: beta)
- OS: Darwin 25.5.0 arm64
- Terminal: WarpTerminal
- Shell: /bin/zsh
- Install/channel: beta, shared background service (
opencode2 service statusreported http://127.0.0.1:) - Active plugins: several local plugins are configured, but all failed schema validation at load time in this session ("Expected object at ["default"]"), so the failure occurred with no custom plugins active.
Reproduction
- Start the TUI against the shared background service.
- Trigger a tool call that opens an interactive question form and leave it pending.
- Drop the client↔server connection while the form is open. In my case the drop happened on its own ~10 minutes into the wait; server logged
location services evictedfor the project directory. - Client silently reconnects (~45 s later; server re-runs location services boot and plugin load).
- Press any key in the still-displayed form (Enter or Esc).
Observed once so far; likely reproducible whenever the connection drops while a form is pending.
Expected Behavior
Either the server persists and restores pending forms across client reconnects, or the client detects the stale form (404 / FormNotFoundError) and dismisses the modal, returning keyboard control to the user.
Actual Behavior
-
On reconnect the TUI replayed its pending answer:
POST /api/session/:id/form/:formId/reply→ 404. -
Every later keypress produced another 404 on
/replyor/cancelplus an unhandled rejection in the CLI log:level=ERROR role=cli message="unhandled rejection" cause._tag=FormNotFoundError cause.message="Form not found: frm_…" -
77 such rejections over ~100 seconds.
-
The modal remained mounted and captured all keyboard input; Esc/Ctrl+C did not work; only killing the terminal recovered.
-
The assistant message was left incomplete with the tool stuck in
running; the session ended asinterrupted.
Additional Context
- Server side of the same window: repeated
Sent HTTP response … http.url=/api/session/<id>/form/<formId>/reply http.status=404and matching/cancel404s after the reconnect. - No pending permission remains queryable afterwards (
GET /api/session/:id/permission→ empty). - Workaround: kill the terminal, start a new session. The run's completed work is intact; only the unanswered question is lost.
- Session/form IDs redacted. Happy to provide a fuller sanitized log excerpt.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.