Prompt is discarded after 'Submission failed' (host-ack timeout): composer cleared, not saved to history, delivered late or never #5264

Describe the bug

When session.send fails because the session host stopped acknowledging events (the #5100 state), the CLI clears the prompt the user just submitted and keeps no copy of it. What happens to the prompt afterwards is unpredictable: sometimes it's delivered later anyway, and sometimes it's never delivered. The CLI shows:

Submission failed: Error: Request session.send failed with message: session event delivery failed: session host did not acknowledge the assistant.reasoning_delta event within 120s

After that, the composer is empty and the text is not put back. Up arrow and Ctrl+R don't find it, and there is no resend option. In the case below:

• One "failed" prompt was most likely delivered 73 seconds later, after the user had been told it failed. Input history points to a late delivery rather than a retype (see the timeline).
• A later multi-paragraph prompt was never delivered. The user had to rewrite it from memory.

Why this happens (from reading the shipped cli-main.js in 1.0.103 and 1.0.104): in the interactive submit path, the prompt is added to input history only in the success branch after session.send resolves. The error branch only emits Submission failed. The pending-submission tracker retires the draft when the send throws, and nothing restores the text to the composer. This means any session.send rejection leaves the user with no copy of the prompt, not only the 120s acknowledgement timeout. Whether the prompt still reaches the agent later is decided out of the user's sight.

How often: since October 23, this machine's retained session data has 20 Submission failed errors across 5 sessions, all with this host-acknowledgement error (the event named varies). #5100 notes that the agent's own output keeps being saved to events.jsonl after delivery fails. The user's input is the one thing nobody keeps a copy of.

Affected version

1.0.103 (copilotVersion in session.start). The same submit and history code is in 1.0.104.

Steps to reproduce the behavior

This isn't deterministic, because it depends on first reaching the #5100 state.

1. Run a long interactive session. Ours was launched through a wrapper that loads several extensions. It used autopilot, many subagents, and a recurring scheduled prompt every 30 minutes. It ran 15 hours with 13 auto-compactions and no resume.
2. Wait until the host stops acknowledging events (Session event delivery permanently fails after one 120s host-ack timeout ("session host did not acknowledge the <event> event within 120s"); session unusable until resume #5100). The first visible sign is Submission failed: ... did not acknowledge ... within 120s.
3. Keep working. Submit prompts while the agent is busy.
4. Some submissions show Submission failed, and each one clears the composer. In our case, after the CLI logged queue drain abandoned, the next failed prompt (14:19:03) was never delivered before the user exited 11 minutes later, and no copy of it remained.

Timeline of the affected session (UTC, 2026-10-27):

Evidence that the 14:19:03 prompt was lost:

• events.jsonl has no user-typed user.message after 14:12:01. The only later user.message is a subagent prompt at 14:14:46.
• The text wasn't restored to the composer.
• It isn't in input history. That file also has a separate overwrite problem (Input history (command-history-state.json) is last-writer-wins across concurrent copilot processes; prompts typed in one session are erased #5265), so the code path above is the stronger evidence here.

Why the 03:00:55 message was most likely a late delivery and not a retype:

1. A second process (call it C) saved two prompts to history at 02:58 and 03:00:13. That process started after this session did, so this session's in-memory history list didn't include those two entries.
2. A third process loaded the history file when it started at 03:01:34, and it wrote the final version of the file at 14:29:54. The final file still contains the 02:58 and 03:00:13 entries.
3. If this session had saved a history entry at 03:00:55, it would have written its own list, which lacked those two entries, over the file before 03:01:34. They survived, so this session saved nothing between 03:00:55 and 03:01:34. Process C didn't write again in that window, because no later C entry from that window appears in the file.
4. In the shipped code, every interactive submit path saves to history when the send call returns. For steering submissions, the submit tracker resolves true once the send returns, and history is skipped only if an internal skipHistory option is set. No Submission failed appeared near 03:00:55, so a retyped prompt's send didn't fail. If it succeeded, it would have saved to history, unless its send took more than 39 seconds to return. The 03:00:55 message was therefore most likely the 02:59:42 prompt, delivered late. Either way, the user was told the 02:59:42 prompt failed and had no copy of it.

Expected behavior

• Save the draft before sending it (for example, in session state), and clear it only after the session confirms it has the prompt.
• If the send fails, put the text and attachments back in the composer, or keep the prompt visibly marked as failed with a resend option.
• Add the prompt to input history whether or not the send succeeds. History records what the user typed.
• Report delivery honestly. If a "failed" prompt is still queued and will run later, don't say it failed. If it's dropped (for example, after queue drain abandoned), say so explicitly.
• If the session is in the permanent failed state from Session event delivery permanently fails after one 120s host-ack timeout ("session host did not acknowledge the <event> event within 120s"); session unusable until resume #5100, say so. Carry unsent drafts across --resume or /restart so they can be resent.

Additional context

• macOS 27.0.1 (26A434), arm64, 96 GiB RAM
• Ghostty, zsh
• Launched through a wrapper that adds several native extensions. Several other interactive copilot processes were running on the same machine.
• events.jsonl for the affected session was 444 MB.
• Related: Session event delivery permanently fails after one 120s host-ack timeout ("session host did not acknowledge the <event> event within 120s"); session unusable until resume #5100 (the root failure state), CLI 1.0.103: persistent session-lock timeouts and unresponsive tasks amid host event acknowledgement failures #5253, and Permission prompts auto-cancelled with "Session host did not acknowledge 'permission.requested' delivery within 5 seconds"; session gets stuck until exit and resume #5018 (same family). Recover queued and pending prompts after agent crash or unexpected exit #1780 asks to recover queued prompts after a crash. Session and prompt lost when stopping an action or hitting the stop button #4477 covers a prompt lost on stop.

The full logs contain private content and can't be shared publicly. I can provide filtered excerpts on request.