VS Code extension crash can leave a thread permanently stuck in "thinking" with queued input

What version of the IDE extension are you using?

26.304.20706

What subscription do you have?

api user

Which IDE are you using?

VS Code

What platform is your computer?

x86

What issue are you seeing?

Summary

If the Codex VS Code extension crashes while a conversation turn is still in progress, the affected thread can get stuck in a permanent "thinking" state in the UI.

After that happens:

• the thread keeps showing as thinking
• I cannot stop it
• I cannot send new input normally
• new input is placed into a waiting queue instead

In my case, this also affected a cloned copy of the same thread, because the underlying persisted thread state was already malformed/incomplete.

Environment

• Codex VS Code extension / Codex local app on Windows
• Workspace was local
• This happened during an active conversation turn, immediately after the extension/plugin crashed

Actual behavior

After restarting Codex:

• the thread still shows "thinking"
• the stop button is not usable
• I cannot type/send new messages normally
• new input is queued instead of starting a new turn
• restarting the app does not resolve it

Expected behavior

If the extension crashes during an active turn, Codex should recover the thread into a safe terminal state, such as:

• aborted
• interrupted
• recoverable draft state

The thread should not remain permanently stuck as "thinking", and I should be able to continue chatting after restart.

What I found locally

I inspected the persisted thread data on disk and found that the affected thread's rollout/session file ended with an unfinished reasoning event.

The broken threads ended with something equivalent to:

• last record type: response_item
• payload type: reasoning

There was no normal terminal event after that, such as a completed/aborted turn marker.

By comparison, healthy interrupted threads on my machine usually ended with something like:

• event_msg
• turn_aborted

Workaround that fixed it

I was able to recover the stuck threads by manually appending a terminal interruption event to the rollout file, effectively marking the unfinished turn as aborted/interrupted.

After doing that, the thread stopped appearing as permanently "thinking" and became usable again.

So the issue seems to be that after a crash, Codex does not always finalize an in-flight turn into a terminal state.

Why I think this is a real bug

This has happened to me more than once, and the symptom pattern is consistent:

1. thread is active
2. Codex extension/plugin crashes
3. after restart, thread is permanently stuck in thinking
4. user input gets queued instead of creating a new usable turn

That strongly suggests crash recovery is not consistently writing or reconstructing the terminal event for the active turn.

Suggested fix

On startup / recovery, if a thread ends in an unfinished in-flight state such as trailing reasoning output without a terminal event, Codex should automatically reconcile it into a safe terminal state like:

• turn_aborted
• interrupted
• or another explicit recoverable status

Also, the frontend should probably avoid treating such a recovered thread as still actively running forever.

Additional note

In my case, cloning the thread did not help, because the cloned thread inherited the same incomplete terminal state and was also shown as permanently thinking until I manually repaired the persisted session data.

What steps can reproduce the bug?

1. Start a normal conversation in the Codex VS Code extension.
2. Send a prompt that keeps the assistant busy long enough to be visibly in a "thinking" / in-progress state.
3. While that turn is still in progress, let the Codex extension/plugin crash unexpectedly.
4. Restart VS Code / restart the Codex extension.
5. Reopen the affected thread.
6. Try to stop the thread or send a new message.

Observed result:

• the thread remains stuck in "thinking"
• stop is not usable
• new input is queued instead of starting a normal new turn

What is the expected behavior?

After restart, the in-progress turn should be marked as interrupted/aborted, and the thread should become usable again.

Additional information

gmail:zhongerkm@gmail.com