VS Code queued follow-ups stop processing after completed turn resumes as markedStreaming=true

What version of the IDE extension are you using?

26.601.21317

What subscription do you have?

Pro

Which IDE are you using?

VS Code

What platform is your computer?

Linux 6.8.0-117-generic x86_64 x86_64

What issue are you seeing?

The VS Code Codex extension task queue can stop processing queued follow-ups after a completed turn is restored as streaming.

I had multiple queued follow-ups in one thread. One task completed, but later queued tasks did not start. The queued follow-ups were still persisted, so the queue had not actually emptied.

Relevant log pattern:

maybe_resume_success conversationId=<redacted> latestTurnStatus=completed markedStreaming=true

I also saw related queue/steering symptoms:

[queued-followups] Failed to release send lock conversationId=<redacted> error={}
Received app server error error={"code":-32600,"message":"no active turn to steer"}

This appears related to #19690, but this report is specifically about the queued-follow-up processor stopping with messages still persisted.

What steps can reproduce the bug?

1. Open a thread in the VS Code Codex extension.
2. Submit a task.
3. While the task is running, queue multiple follow-up messages in the same thread.
4. Let one queued task complete.
5. Reload/restart VS Code or otherwise trigger thread resume.
6. Check the Codex log.
7. In the failing case, the latest turn is completed but resume logs markedStreaming=true.
8. The queued follow-up list still contains messages, but the queue stops processing them.

No code snippet is involved; this appears to be extension/session queue state.

What is the expected behavior?

A completed turn should not be restored as actively streaming.

If queued follow-ups remain and the latest turn is completed, the extension should start the next queued follow-up instead of leaving the queue stopped.

The queue should not require an already-active stream in order to start the next queued turn after a completed turn.

Additional information

Possible fix direction from local debugging:

• Only mark a resumed/snapshotted conversation as streaming if the latest turn is inProgress.
• Clear streaming state on terminal turn/completed.
• Do not restore queued follow-ups with pausedReason after a normal completed turn.
• Ensure queued follow-up send-lock release succeeds.
• Treat stale no active turn to steer / active_turn_not_steerable as inactive-turn queue state.
• Allow starting the next queued follow-up after a completed turn.