[Desktop + CLI] New thread first turn waits on WebSocket retries before falling back to HTTPS

Resolved 💬 3 comments Opened Apr 28, 2026 by rzv-me Closed Apr 28, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

This is happening in both the CLI and the Desktop app

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

Desktop: Version 26.422.62136 (2180)
CLI: v0.125.0

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

macOS 25.3.0 arm64 arm

What issue are you seeing?

Starting today, new threads hit a WebSocket reconnect loop on the first turn before falling back to HTTPS. In Desktop, one visible symptom is that thread title generation times out and the title remains equal to the first message.

When the first message is sent, Codex creates the thread and initially uses the first user message as the thread title. Normally, the title service should later replace that with a shorter generated title. In my case, that replacement never happens: the thread title stays equal to the first message.

At the same time, the UI shows Reconnecting... 2/5 through 5/5.

The CLI gives this error message, after the Reconnecting loop: ⚠ Falling back from WebSockets to HTTPS transport. timeout waiting for child process to exit

This basically creates a ~100s delay for each new thread I start

Relevant logs for the Desktop App:

2026-04-28T12:14:22.413Z info [electron-message-handler] Conversation created conversationId=019dd403-0812-7451-9051-5ba7cc8aaeb2
2026-04-28T12:14:22.419Z info [AppServerConnection] response_routed ... method=turn/start conversationId=019dd403-0812-7451-9051-5ba7cc8aaeb2
2026-04-28T12:14:23.072Z error [electron-message-handler] Received turn/started for unknown conversation conversationId=019dd403-0ad3-74e1-9bd3-fc5cbb1017ff
2026-04-28T12:14:53.072Z warning [electron-fetch-handler] Failed to generate thread title errorMessage="Timed out waiting for structured result."

2026-04-28T12:12:25.626Z info [electron-message-handler] Conversation created conversationId=019dd400-ab23-7ff3-9ff0-15a302770219
2026-04-28T12:12:25.634Z info [AppServerConnection] response_routed ... method=turn/start conversationId=019dd400-ab23-7ff3-9ff0-15a302770219
2026-04-28T12:12:26.309Z error [electron-message-handler] Received turn/started for unknown conversation conversationId=019dd401-42a0-7a10-ad79-e90fee18d497
2026-04-28T12:12:56.310Z warning [electron-fetch-handler] Failed to generate thread title errorMessage="Timed out waiting for structured result."

Relevant logs for the CLI:

transport="responses_websocket" websocket.warmup=false
close time.idle=15.0s
stream disconnected - retrying sampling request (1/5 ...)
...
stream disconnected - retrying sampling request (5/5 ...)
codex_core::client: falling back to HTTP
transport="responses_http"

What steps can reproduce the bug?

  1. Open Codex Desktop on macOS.
  2. Start a new thread by sending a first message.
  3. Observe that the thread is created and the sidebar title is initially set to the first message.
  4. Wait for the automatic title-generation step.
  5. The UI shows Reconnecting... attempts.
  6. The sidebar title never gets replaced by a generated title and remains the first message.

This started happening today and reproduced across multiple new threads.

What is the expected behavior?

After a new thread is created, Codex should start the first user message immediately. Thread title generation should happen asynchronously in the background.

The first message/turn should not wait for title generation to complete. If title generation fails or times out, the conversation already continued normally and the thread can keep the initial first-message title until a generated title is available.

Additional information

This may be related to #18471, but my reproducible symptom is specifically around new-thread title generation. The thread is created successfully, but title generation times out and the initial first-message title is never replaced.

The repeated log line is:

Failed to generate thread title errorMessage="Timed out waiting for structured result."

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #18471
  • #19983

Powered by Codex Action

rzv-me · 4 months ago

after disconnecting an reconnecting my Ethernet adapter, it seems to work ok

WilliamSoler · 3 months ago

I hit this on Linux with codex-cli 0.128.0: every new session showed Reconnecting... 2/5 ... timeout waiting for child process to exit, then eventually Falling back from WebSockets to HTTPS transport.

In my case the root cause was broken IPv6 routing. The machine had IPv6 addresses and chatgpt.com resolved to IPv6 first, but IPv6 egress timed out.

Useful checks:

getent ahosts chatgpt.com
curl -4 -I --connect-timeout 5 --max-time 10 https://chatgpt.com/backend-api/codex/responses
curl -6 -I --connect-timeout 5 --max-time 10 https://chatgpt.com/backend-api/codex/responses
ping -6 -c 3 -W 2 2606:4700:4700::1111

For me:

  • IPv4 returned immediately.
  • IPv6 timed out.
  • After making the system prefer IPv4, Codex started normally again. A minimal codex exec test went from timing out after ~75-90s to completing in ~4s.

Workaround on Linux/glibc:

sudo cp /etc/gai.conf /etc/gai.conf.bak.codex-ipv6

sudo tee -a /etc/gai.conf >/dev/null <<'EOF'

# Prefer IPv4 because this network advertises IPv6 but IPv6 egress times out.
precedence  ::1/128       50
precedence  ::/0          40
precedence  2002::/16     30
precedence ::/96          20
precedence ::ffff:0:0/96  100
EOF

Then restart Codex and verify:

getent ahosts chatgpt.com | head

IPv4 should appear before IPv6.

This is not really a Codex-only issue: Codex just exposes it because ChatGPT-auth traffic uses chatgpt.com and the WebSocket/new-thread path seems sensitive to the broken IPv6 route.