An annotation sent with "Steer" now makes the active chat go blank while its turn continues invisibly and triggers about 60 thread-resume attempts per second

What version of the IDE extension are you using?

openai.chatgpt 26.5818.61809-darwin-arm64

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

The behavior reported in #40446 changed after updating the extension from 26.5727.51351 to 26.5818.61809.

It is now partially "fixed": the active-writer protection prevents the other VS Code windows from actually starting duplicate turns and writing to the same rollout and workspace concurrently. In both new reproductions, only one successful turn ran and only one file with one ordered TICK sequence was created.

However, an annotation sent with Steer still makes the other VS Code windows try to resume the same chat and become its owner. Their thread/resume requests then fail with thread-store conflict: thread ... already has an active writer, but by that point the original visible window has already been demoted from owner to follower, and its ownership is not restored.

Immediately after clicking Steer, the active chat goes blank and remains blank while the original turn keeps running "invisibly" and modifying the workspace. At the same time, the visible client remains stuck in the resuming/follower state and logs maybe_resume_started about 60 times per second. The loop continues even after the actual turn finishes. In one reproduction it exceeded 22,000 attempts and rotated the extension log.

So the new protection prevents the destructive concurrent writes from #40446, but the underlying cross-window ownership problem remains and now produces a different failure mode.

What steps can reproduce the bug?

Repeat the reproduction steps from #40446 with the extension version listed above.

After clicking Steer in step 6, the duplicate turns are rejected by the active-writer protection, but the visible chat immediately goes blank while its existing turn continues running. The resume loop described above starts at the same time.

I reproduced this twice after updating the extension.

What is the expected behavior?

The annotation should be handled exactly once by the current owner. Other VS Code windows should not try to resume the chat or take ownership from its active client.

The active chat should remain visible and continue showing its running turn, and no client should enter a continuous resume loop.

Additional information

Relevant extension log sequence from a clean three-window reproduction:

18:38:13.063  dormant windows: maybe_resume_started; previousResumeState=needs_resume; previousStreamRole=null
18:38:13.076  dormant window: role=owner
18:38:13.089  original visible window: role changed from owner to follower
18:38:13.105  dormant windows: thread-store conflict; thread already has an active writer
18:38:13.124  original visible window: maybe_resume_started; previousResumeState=resuming; previousStreamRole=follower
18:38:13.156  same maybe_resume_started event repeats, continuing at about 60 times per second

Bundled Codex CLI: 0.149.0-alpha.4.3

Start by repeating the reproduction steps from #40446 with the listed VS Code extension and Bundled Codex CLI versions, then inspect the extension logs around maybe_resume_started, resuming/follower, and thread-store conflict. Done means the current owner handles the Steer annotation once, the active chat remains visible, other windows do not take ownership, and no continuous resume loop occurs.