tui: initial user message can be missing from a new session

[opencode-agent]

Summary

In the V2 TUI, the initial user message can be missing from a new session even though the assistant response renders normally. This appears correlated with slow MCP server startup, but that cause is not yet confirmed.

Environment

• opencode version: local V2 development build
• OS: Unavailable: not captured in the report
• Terminal: Unavailable: not captured in the report
• Shell: Unavailable: not captured in the report
• Install/channel: local development build
• Active plugins: Unavailable: not captured in the report

Reproduction

1. Configure one or more MCP servers that are slow to initialize.
2. Start the V2 TUI and submit the first prompt in a new session.
3. Wait for the assistant response to render.

Expected Behavior

The initial user message appears in the session before the assistant response.

Actual Behavior

The initial user message is absent from the transcript. The assistant response and subsequent session UI render normally.

Additional Context

Observed by multiple team members. In the captured occurrence, the session showed the assistant greeting (Hi! How can I help you?) and its timing metadata, but no preceding user message. Slow MCP initialization is the leading suspicion and still needs confirmation with a minimal reproduction.

[kitlangton]

Reproduced again on next-15329 in session ses_0ae677effffeBLVh4NgPzVuJ8S.

The initial input msg_f519881de001UR8nhn9Dr3vLxW is intact in durable state (session.input.admitted seq 1, session.input.promoted seq 4) and is the first materialized session_message at seq 4. It contains the full text and image attachment, but the TUI transcript starts with the assistant response and only shows later user messages. This confirms another API/persistence-correct, TUI-hydration-only occurrence matching the race described here and in #36176.

[kitlangton]

Reproduced twice again on 0.0.0-next-15615, including in the session used to report the first occurrence. Both prompts are durably admitted, promoted, and materialized as the first session_message at seq 4, but the TUI starts with the assistant output.

• ses_098ecc32effeJqDR6o13EQLZcJ: session.input.admitted.1 seq 1, session.input.promoted.1 seq 4, user message msg_f67133d9a001zEt0VdK2AFL36j at materialized seq 4
• ses_098ec73a6ffe3Vi9UvkIxDXMHT: same event ordering, user message msg_f67138ca0001SY1Wg70NG9T7lc at materialized seq 4

Environment: macOS 25.5.0 arm64, WarpTerminal, next channel. The managed service and client both report 0.0.0-next-15615. This is still reproducible after #36176 was closed without merging, and does not appear to require slow MCP startup.

[kitlangton]

The fix PR is updated and mergeable against current v2: #36433.

The current implementation removes the unsafe parallel pending/history hydration. It loads and reconciles pending work first, then projected messages, preserving live admissions and promotions that arrive during either request. This covers both next-15615 reproductions without temporary client-only message IDs. Local TUI tests and typecheck pass; CI is running.

[opencode-agent]

Addressed by #38542. For a newly created Session, the V2 TUI now treats the subscribed session.created event as the start of its local timeline and lets ordered live admission/promotion/message events populate the initially empty caches. This removes the pending-versus-projected hydration window that could lose the first user message despite correct durable state. Focused TUI regression tests and a real before/after reproduction passed. Closing as resolved on the v2 branch.