[Feature]: Preserve pending native user questions across server restarts

[hahasagined]

Summary

A pending native Codex request_user_input question becomes permanently unanswerable after a normal server restart. Please preserve supported pending questions durably, and resume the original conversation only after the user answers.

This was reproduced with a real provider conversation on stock 0.1.2-nightly.20261022.3512 (Linux, headless T3 in a Coder workspace), using a single server and its existing data directory. The server was stopped and started on the same runtime and workspace template; this was not an upgrade or a shared-data-directory/two-writer setup.

Reproduction

1. Start a Codex conversation in plan mode and ask it to call the native blocking request_user_input tool with a simple Alpha/Beta choice. Tell it to repeat the chosen answer after receiving it.
2. Confirm that the request is pending and has responseCapability: { "type": "live" }. Leave it unanswered.
3. Stop and start the server while retaining its data directory. Our test used the supported Coder workspace stop/start lifecycle on an unchanged template.
4. Inspect the original question and attempt to answer that original request.

Actual result

After startup, the original request was:

{
  "kind": "user_input",
  "status": "expired",
  "responseCapability": {
    "type": "not_resumable",
    "reason": "The server restarted before this runtime request was resolved."
  }
}

The waiting run was cancelled. runtime-request.respond for the original request was rejected with Runtime request <id> is expired. No continuation run was created. All pre-existing conversation identities and message hashes were retained, as were settings and authentication/Connect state; the loss is specifically the ability to answer the pending question and continue it.

Expected behavior

For providers and native conversation identities that support safe resumption:

• Keep the original question and request identity durably across shutdown/startup.
• Keep it answerable after startup, without choosing an answer on the user's behalf.
• Do not automatically continue the waiting conversation before an answer arrives.
• After an answer, resume the correct native conversation exactly once, including if duplicate answer submissions race or recovery runs again.
• Do not reopen answered questions or turn manually cancelled requests back into pending questions. Requests that cannot safely resume, including unsupported permission/secret requests, should keep explicit safe handling.

If preserving a process-bound native callback is unsupported, a durable answer/message continuation path would meet the user need. This may be a feature request rather than a regression; the current expiration appears intentional, but it prevents safely restarting otherwise idle servers with unanswered questions.

Impact

Routine maintenance must wait for every blocking question to be answered, or it loses the original question's answer path. An agent waiting for a human may remain parked for hours or days even though no work is actively executing.

Related issues

• [Bug]: A pending AskUserQuestion card stays answerable after a server shutdown cancels it as not_resumable #18079 and [Bug]: Pending user-input popup can never be dismissed after the provider session dies (e.g. server restart) #5454 concern stale question UI after the request has become unanswerable. This report asks to retain answerability itself. It does not claim that an expired card still offers Submit.
• [Feature]: expose "waiting on user input" on the session, not just status=running #15900 concerns exposing waiting versus working status.
• [Bug]: Async questions make a running thread show as Awaiting Input #15258 concerns async questions incorrectly masking active work.
• MCP orchestration tools fail with parent_not_active after a provider handoff, a notification turn, or a question; a restart mid-turn kills the thread #23006 includes a different restart failure involving Claude provider sessions/orchestration ownership.

Validation limits

The real-provider restart and rejection above were observed directly. Correct-conversation/exactly-once resumption could not be tested on this stock build because the request expired first. No production question was answered for its owner.