VSCode Codex chat stuck on "thinking" after system crash

[GregPeden]

What version of the IDE extension are you using?

0.4.79

What subscription do you have?

Plus

Which IDE are you using?

VSCode

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What issue are you seeing?

I had a Codex task running in VSCode when my system hung up. I forced a restart. The task which was running is stuck with the "thinking" animation and I cannot get control back. The stop button is present but it has no effect.

I was able to submit another message and tell it to "steer" (ie. submit the message right away), then the agent acknowledged and resumed.

I've had crashes like this before, either my system, WSL2 or VSCode, and in all other cases the chat was just stopped in state and I was able to ask the agent to resume.

What steps can reproduce the bug?

• Start a Codex chat.
• Do something dumb which makes your system hang then force restart.
• Roll a D20 for critical hit or rub your rabbit's foot.
• Return to VSCode and find the conversation stuck in "thinking" state.

What is the expected behavior?

Chat should be halted or at least responsive to "stop" button.

Additional information

I'm Running VSCode in Windows 11 with WSL2 hosting for web services via Docker. Using WSL:Ubuntu remote linking in VSCode.

[etraut-openai]

Does this occur only for the one thread that was active when the crash occurred? I'm wondering if it might be explained by a corrupt rollout file. Perhaps it was only partly written to disk because of the crash.

If you still have that thread around, could you load it and try to use the /feedback slash command to upload the rollout file? If you post the thread ID here, then I could take a look at it to see if it looks corrupt in any way.

[GregPeden]

Done. ID: 019cb009-2ca8-72e3-8eb0-c969fb91850a

For context, I was running another graphically-rich application on a Surface Pro 9 tablet with 16 GB of RAM and that other application crashed and caused my system to hang. I had to force the restart with the power button. I am often memory-constrained on this device.

[etraut-openai]

That's an enormous rollout file — more than 127MB. For comparison, most of my rollouts are 5 to 10MB, and the largest one I've produced in the past month is 30MB. I tend to create a new thread for every task. You may want to try breaking up your work into separate threads, especially if your machine is so memory constrained. That could be contributing to your out-of-memory problems.

Your rollout file is syntactically correct, so that eliminates my theory that the file might have been truncated due to a partial file write. My best guess is that it was saved at a point where the agent loop isn't able to recover. Validating that theory will require more time than I can devote to this issue, unfortunately.

[GregPeden]

No worries, I only shared it because it was the first time it happened. Definitely not a very serious issue given that the crash happened outside of the scope of Codex, but it has handled crashes well many times so I decided to share.

I don't know why the file is so big but I do indeed run separate threads for separate tasks / reach goals. Besides, honestly, Codex was totally nailing it - the agent was performing well and producing good results. I saw no evidence of the model struggling. I see it running auto compaction now and then and that has worked great. But I don't have a habit of running one monolith convo which I steer toward different things.

[GregPeden]

Just happened again while doing sweeping repair of units tests, this time while Codex was just running with nothing else happening on my system. There was no crash, the IDE just "lost connection" to the WSL2 environment. This is DEFINITELY one of the biggest session runs I have ever done so I'm sharing it case it helps.

In the past i just found the chat waiting for the next message, now it says "thinking" and looks like it's working when it's not.

019cb681-65f6-7500-866e-98d58835cdfc

[GregPeden]

I had an insight which I think is relevant.

I observed another issue existing in the VSCode implementation for a couple weeks where the chat window usually failed to update with changes from the agent until I start scrolling around. I learned to just try scrolling once in awhile to make sure I'm seeing the latest. This issue is now fixed in the latest release.

But I wager that the issue I saw related, and that the chat window was not showing the correct latest state... but in this crash-and-restart case I couldn't kick it to refresh.

I suspect that the fix to the scroll issue also fixed my client not being up to date after a crash.

[mike-marshall]

Seeing this as well. Fairly small project (3 small .NET projects in a solution). In my case, I was prompted to "Sandbox" the agent first. I had been working for about a month with it but that was the first time I had seen it. Not sure if that is a Codex thing or that is a VSCode feature that kicked in. Once I approved that, VSCode seemed to reload everything, brought me back to my session. It seemed like it was running the prompt I put in before all this happened, but it is stuck "Thinking" and the Stop button does nothing. It even persists after closing and opening VSCode

Here is my feedback ID: 019ccf49-52e9-7680-ab52-9a86f6f5a13c