Codex QueueStrip can keep processed follow-up prompts stuck after idle #241

Problem

Saved debug bundles show a Codex queued prompt remaining in QueueStrip after the agent has already processed it and the session has returned to idle. This is separate from the earlier user-prompt ordering issue: here the stale queue item is still present in state-snapshot.json, so the HTML is faithfully rendering bad runtime state rather than merely leaving behind a stale DOM artifact.

Evidence

Saved debug manifest notes:

• 2026-05-19T09:23:48.299Z note on bundle ~/.config/agent-code/debug-bundles/2026-05-19T09-23-36-093-21e655e8: weird thing? que is not cleared in this example UI wise.
• 2026-05-19T09:26:18.873Z note on bundle ~/.config/agent-code/debug-bundles/2026-05-19T09-26-14-911-21e655e8: same issue, no user propmt

First bundle state:

• manifest captured at 2026-05-19T09:23:35.966Z
• sessionStatus: running
• streamPhase: thinking
• processActive: true
• queuedMessages.length: 1
• queued timestamp: 1779182503356 (2026-05-19T09:21:43.356Z)
• queued content begins: After that, you can post a new issue for me. Actually, can you read the two scripts we had left? ...

Second bundle state:

• manifest captured at 2026-05-19T09:26:14.828Z
• sessionStatus: idle
• streamPhase: idle
• processActive: false
• awaitingAssistant: false
• queuedMessages.length: 1
• same queued content and timestamp still present

HTML confirms the queue strip is rendering from state:

<div ... aria-label="queued messages">
  <div ...>1 queued</div>
  ... After that, you can post a new issue for me ...
</div>

The later screen / recentScreen in the same idle bundle do not contain that queued prompt text, but they do contain later assistant output and later user input. The assistant clearly progressed through subsequent turns while the local queue surface remained stuck.

Likely Cause

addOptimisticCodexUserEntry() queues follow-up Codex submits when shouldQueueOptimisticCodexUserEntry() sees a live semantic turn. The clearing path in useIpcSubscriptions.ts removes a queued item only when an authoritative Codex rollout user row maps to matching prompt text:

if (queuedMessages.some(q => codexPromptsMatchForOwnership(q.content, mappedText))) {
  queuedMessages = queuedMessages.filter(q =>
    !codexPromptsMatchForOwnership(q.content, mappedText),
  )
}

That assumes every queued follow-up will later appear as a committed user rollout entry. The saved bundle disproves that assumption: the prompt was submitted/processed, but no matching committed user row arrived in the captured durable feed, leaving queuedMessages permanently non-empty.

Desired Behavior

A queued prompt should not remain visible after the app has convincing evidence that the queued turn has been accepted or superseded.

Potential fixes to investigate:

• Clear the head queued item when a queued follow-up transitions into a new provider turn, even if no committed user rollout row arrives.
• Add an idle/session-complete reconciliation guard: if streamPhase === 'idle', processActive === false, and awaitingAssistant === false, queuedMessages should be empty unless the provider explicitly reports pending queued work.
• Emit feed-debug events when queue items are added, reconciled by committed user row, or force-cleared by lifecycle state, so future saved bundles show exactly which invariant fired.

Acceptance Criteria

• Add a regression fixture/script for: queued Codex follow-up, provider responds, no matching committed user rollout row, session returns idle.
• The queued strip disappears by the time the session is idle.
• Existing behavior still preserves genuinely pending follow-up prompts during an active semantic turn.
• Saved debug bundle state cannot show sessionStatus: idle, streamPhase: idle, processActive: false, awaitingAssistant: false, and queuedMessages.length > 0 for a Codex pane unless there is a real provider queue signal explaining it.

Related

• Optimistic submitted user prompts are buried behind semantic/work rows #239 tracks submitted user prompts being present but visually buried behind semantic/work rows. This issue is different: queuedMessages itself remains stale.