anomalyco / anomalyco/opencode

tui: pending question form lost after client reconnect — unexitable modal (FormNotFoundError loop)

Open
#44,471 0 comments 0 reactions 1 assignee View on GitHub

@kommander is already working on this.

Since Aug 23, 2026.

2.0
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 status reported 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

  1. Start the TUI against the shared background service.
  2. Trigger a tool call that opens an interactive question form and leave it pending.
  3. 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 evicted for the project directory.
  4. Client silently reconnects (~45 s later; server re-runs location services boot and plugin load).
  5. 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 /reply or /cancel plus 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 as interrupted.

Additional Context

  • Server side of the same window: repeated Sent HTTP response … http.url=/api/session/<id>/form/<formId>/reply http.status=404 and matching /cancel 404s 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.