tui: pending forms become unanswerable after managed service restart #36585

Summary

A pending TUI form remains visible after a managed-service restart, but submitting it fails because the replacement server no longer has the form in its process-local cache. This leaves the user looking at an actionable form that can never be answered.

@kitlangton encountered this during an automatic next-channel upgrade.

Environment

• opencode version: Form created on 0.0.0-next-15386; failure observed after automatic upgrade to 0.0.0-next-15388
• OS: macOS 25.5.0, Darwin 25.5.0 arm64
• Terminal: WarpTerminal, TERM=xterm-256color, COLORTERM=truecolor
• Shell: /bin/zsh
• Install/channel: global opencode2, next channel, managed background service
• Active plugins: ~/.config/opencode/plugins/share-with-team.ts, packages/opencode/src/control-plane/dev/debug-workspace-plugin.ts, @warp-dot-dev/opencode-warp

Reproduction

1. Open a TUI session and let the agent create a question/form.
2. Leave the form pending.
3. Restart or automatically upgrade the managed service while the form is visible.
4. Reconnect to the session and submit an answer.

Expected Behavior

The pending form should remain answerable after reconnect, or the TUI should recognize that it is no longer live and dismiss or replace it with a recoverable state.

Actual Behavior

The TUI continues rendering the form and accepts local selection/editing, but submission fails with:

Form not found: frm_f59082e560014GRjWpWb32sAxO

The API confirms the stale state:

{"_tag":"FormNotFoundError","id":"frm_f59082e560014GRjWpWb32sAxO","message":"Form not found: frm_f59082e560014GRjWpWb32sAxO"}

Additional Context

The restart timeline is deterministic in the local logs:

2026-07-13T01:14:18.597Z updated OpenCode from=0.0.0-next-15386 to=0.0.0-next-15388
2026-07-13T01:14:41.678Z old managed server begins shutting down
2026-07-13T01:14:43.281Z replacement 0.0.0-next-15388 service starts

The service remained healthy after replacement:

{"healthy":true,"version":"0.0.0-next-15388","pid":25498}

The likely boundary is packages/core/src/form.ts: forms and their pending state are stored in a location-scoped in-memory Cache. The TUI retains the rendered form across reconnect, but the replacement location graph has no matching cache entry. There is no form persistence table in the next-channel database, and querying the exact form ID on the replacement server returns FormNotFoundError.

Session messages otherwise continued after the service replacement, so this is specifically stale/lost form state rather than a generally dead session.