Windows desktop app: every new thread shows "Reconnecting... timeout waiting for child process to exit" during startup websocket prewarm

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

• #21167
• #21296

Powered by Codex Action

it is solved. when using the VPN , it will cause this issue. either ask Codex try to fix this on this point or refer to this guide for steps by steps. https://www.gitapp.net/docs/blog/codex-reconnecting-http-sse.html

it is solved. when using the VPN , it will cause this issue. either ask Codex try to fix this on this point or refer to this guide for steps by steps. https://www.gitapp.net/docs/blog/codex-reconnecting-http-sse.html

按照这个修改以后，确实可以解决Codex的重连问题，但是会导致新的bug ,对话记录缺失。
如果你把 Codex Desktop 从默认 openai provider 切到 HTTP-only provider，例如 openai_http，新会话确实可能不再反复 reconnecting，但也可能带来一个副作用：右侧历史列表只显示 openai_http 下的新对话，旧的 openai 对话看起来像丢了。

旧记录通常没有真的丢。它们还在本机的 Codex 数据目录里，只是 provider 名称分裂了：

旧对话: model_provider = openai
新对话: model_provider = openai_http
修复方法不是把自定义 provider 强行命名为 openai。更稳妥的做法是：以当前 config.toml 里的 model_provider 为目标，把旧历史里的 openai 迁移到当前 provider，并同时更新 SQLite 索引和 JSONL 源文件。

核心原因是module provider 改变了。 所以修改的时候需要注意点， 具体可以参照https://www.gitapp.net/docs/blog/codex-history-provider-fix.html

I hit a very similar reconnect loop on Windows Codex Desktop with gpt-5.5, where every new thread showed Reconnecting... 1/5 ... 5/5.

What fixed it for me was not changing away from gpt-5.5. The working workaround was:

1. Keep the model as gpt-5.5, but reduce startup pressure by using model_reasoning_effort = "medium" temporarily.
2. Disable Desktop startup feature sync paths that were failing/retrying in the background:

model = "gpt-5.5"
model_reasoning_effort = "medium"

[features]
apps = false
browser_use = false
browser_use_external = false
in_app_browser = false
computer_use = false
plugins = false
tool_search = false
tool_suggest = false
workspace_dependencies = false

1. Make sure the Desktop/child process actually inherits the proxy. In my case the Windows user proxy was set to 127.0.0.1:10808, but Codex child processes were not reliably using it. Setting user-level env vars fixed the model call path:

setx HTTP_PROXY "http://127.0.0.1:10808"
setx HTTPS_PROXY "http://127.0.0.1:10808"
setx ALL_PROXY "http://127.0.0.1:10808"
setx NO_PROXY "localhost,127.0.0.1,::1"

Then fully quit Codex Desktop, make sure the local proxy is running, and restart Codex.

Extra note: netsh winhttp show proxy showed Direct access on my machine while the user proxy was enabled. Syncing WinHTTP may also be needed when Desktop still fails:

netsh winhttp import proxy source=ie

After the env proxy variables + feature-disable config, gpt-5.5 worked again. CLI also confirmed model: gpt-5.5, provider: openai, and returned normally through the proxy.

I also tested a custom model_provider with supports_websockets = false, but that was not a usable workaround for ChatGPT auth in my setup because it routed to https://api.openai.com/v1/responses and failed with missing api.responses.write scope. So I would not recommend that workaround for ChatGPT-auth Desktop users.

I can reproduce a very similar issue on the new Windows desktop app.
Environment
ChatGPT Windows app: 26.715.2236.0
Windows 11 Pro Insider Preview, build 26220.8764
Proxy is configured through WinHTTP / Clash Verge

Regular Chat works normally in the desktop app. Existing/historical Work conversations can also send messages successfully. However, every newly created Work conversation remains indefinitely stuck on “Sending”; Codex is affected as well.
The same account works normally in ChatGPT Work on the web. I have also reproduced this after reinstalling/resetting the app, flushing DNS, syncing system time, and switching proxy nodes.
This seems more consistent with a Windows Desktop new-conversation/session-initialization issue than a general connectivity failure. I have also reported it to OpenAI Support.