Codex Desktop cannot create active thread on Windows

Open 💬 2 comments Opened Jun 30, 2026 by joseferocheita-dotcom

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.623.70822

What subscription do you have?

PLUS

What platform is your computer?

Windows 11

What issue are you seeing?

Title:
Codex Desktop cannot create active thread on Windows

Description:

Codex Desktop Version:
26.623.70822

Windows 11
ChatGPT Plus

Every message fails immediately with:

"No se puede enviar el mensaje"

The performance trace generated the following incident id:

no-active-thread-019f1995-a586-7c21-b0d6-09d3be931158

The application starts correctly.
Models are available.
WSL2 works.
Ubuntu 24.04 is installed.
Node.js is installed.

The error happens even in a brand new chat with a simple message such as "Hello".

What steps can reproduce the bug?

Uploaded performance trace: no-active-thread-019f1995-a586-7c21-b0d6-09d3be931158

What is the expected behavior?

When i want to make a dialog with the model it gives the error: It cant send the message , Loading..

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#29632
#29311
#29421

Powered by Codex Action

fibo-blip · 1 month ago

This may be related to an older but still-open Windows session-state issue: #14251.

I hit a current Windows Desktop case with the same user-visible family of symptoms (Unable to send message / Loading...), but local diagnostics pointed away from auth/network/plugin failure:

WSL mode runtime was healthy
codex doctor reported auth/network/websocket OK
disabling recently added plugins did not fix it
stale remote-control selection was not active in the failing run (hostId=local, remote connection count 0)

The decisive log pattern was:

maybe_resume_success
latestTurnStatus=interrupted
markedStreaming=true

The affected local session JSONL had an interrupted turn ending with turn_aborted but no terminal assistant message / task_complete. Backing up the session file and appending a terminal assistant message plus task_complete for that interrupted turn_id made the Desktop composer usable again.

I posted the fuller sanitized details here: https://github.com/openai/codex/issues/14251#issuecomment-4853528225

So at least one current Windows Unable to send message / Loading... case is caused by stale streaming state after an interrupted turn, not by connectivity or WSL runtime failure.