Repository navigation
Stuck on "Thinking", trying to send steers but it flickers instead of ingesting requests #16265
Description
What version of the IDE extension are you using?
26.325.31654
What subscription do you have?
Plus
Which IDE are you using?
VS Code 1.113.0
What platform is your computer?
Windows 11 25H2 26200.8037
What issue are you seeing?
WhatsApp.Video.2026-03-30.at.20.33.19.mp4
I tried to click on Stop button - it doesn't work
I tried sending steers - it flickers like in the animation
What steps can reproduce the bug?
I had to terminate the vs code window workspace and re-enter it
then the bug resolved itself, but still thought it was worth reporting in case it reproduces in the future
I have this unconfirmed theory that openning another workspace window while codex is still working on the original task in the original workspace window might have caused this because it was the only out of the ordinary thing I did when this reproduced originally
What is the expected behavior?
"Stop" would work, "Steer" would not flicker and would work, stuck on "Thinking" without showing any actual progress would cease after a short while
Additional information
No response
Activity
github-actions commentedon Mar 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
RohinJ444 commentedon Sep 19, 2026
Seeing a similar flickering/failed-Steer symptom in the Codex desktop experience on macOS, rather than the VS Code extension.
While the agent is running a command:
In the current occurrence, more than 10 minutes have passed since the initial attempt, and several additional attempts have produced the same result. This is not just a delayed acknowledgement: the UI keeps reverting to the queued state. The agent has been running an SSH command for approximately 53 minutes. I have not established whether the command duration is related to the failure.
This has happened multiple times. I have only observed it with Astra / since Astra was released; I have not done a controlled comparison with other models, so this is an observation rather than a confirmed model-specific cause.
Environment: macOS 26.6.2 on Apple Silicon; host desktop app version 26.915.31945, build 9922 (read from installed app metadata).
Expected: clicking Steer should either accept the instruction with a clear pending/delivery state or show an actionable failure, rather than flash and silently return to the queued state. I am not requesting automatic cancellation of the running command.
Private task identifiers, transcripts, SSH host details, and command text are intentionally omitted. This may be related to the original report, but I have not confirmed a shared root cause.