Repository navigation
# Windows desktop startup stays at splash until local app-server is terminated #49506
Description
What version of the Codex App are you using (From “About Codex” dialog)?
- Microsoft Store package: OpenAI.Codex 26.928.1915.0; package Status: Ok.
What subscription do you have?
plus
What platform is your computer?
- Windows 11 x64, OS release 10.0.26200.
What issue are you seeing?
Windows desktop startup stays at splash until local app-server is terminated
Environment
- Windows 11 x64, OS release 10.0.26200.
- Microsoft Store package: OpenAI.Codex 26.928.1915.0; package Status: Ok.
- Desktop build/version label: 26.928.20755.
- Bundled local app-server: 0.159.0.
- Reproduced on earlier 26.924.2738.0 / 26.924.6891.0 packages and current installed version.
User-visible behavior
Normal startup remains on a blank splash screen with a centered OpenAI logo. Previously it showed a spinner. The user can enter the UI by manually terminating the initial local codex.exe app-server; the desktop host starts another app-server and the UI appears. This is required even when the account was already signed in before application launch. Please do not interpret the initial process exit as a spontaneous crash: the user intentionally terminated it.
Reproduction
- Sign in, then fully exit the desktop app.
- Launch normally from the Start menu/Store app identity.
- Observe the splash persisting despite successful backend initialization and account lookup.
- Terminate the initial local codex.exe app-server from Task Manager.
- The desktop host reconnects; the home and sidebar appear within several seconds.
Failed remediation already tested
- Multiple Store reinstalls and app updates.
- Removal of a previously used custom theme.
- Restoration of installation to the C: volume.
- Rebuilding the Chromium profile.
- Simultaneous backup/removal of the Chromium profile and Codex auth.json, followed by a fresh sign-in. Both were demonstrably recreated; startup still failed.
Timeline from one current-version reproduction
Times below are local Asia/Shanghai on 2026-09-30. Raw desktop log timestamps are UTC.
| Time | Event |
|---|---|
| 13:35:39.427 | Initial local app-server process 20872 spawned |
| 13:35:39.528 | initialize handshake succeeded in 100ms |
| 13:35:42.106 | account/read succeeded in 5ms; getAuthStatus also succeeded |
| 13:35:43.679 | ChatGPT account lookup succeeded; authenticated account present |
| 13:35:47.744 | configRequirements/read succeeded |
| 13:35:49.518 | durable backend websocket initialize succeeded |
| 13:35:50.074 | pubsub subscriptions succeeded |
| 13:35:50.771 | Local Work executor connected to rendezvous |
| 13:35:58.126 | codex_app MCP tools/list timed out after 10s |
| 13:36:07.550 | User terminated initial local app-server; stdio closed with code 1 |
| 13:36:07.700 | Replacement local backend initialized successfully |
| 13:36:10.774 | app_start success; shell_visible, home_visible and sidebar_ready appeared |
Desktop log identifier: codex-desktop-864aa159-39d9-44ef-8a5f-6343b931f534-34604-t0-i1-053539-0.log.
Diagnostic interpretation and questions
- The problem is not limited to a first-login auth hot-reload: it also reproduces with credentials already present, successful account lookup, and a normal account/read response.
- The observed
Authenticated workspace changedandDesktop network policy does not allow this destinationmessages in this reproduction start after the user terminates the backend; they may be recovery side effects rather than the initiating problem. - An MCP tools/list timeout is observed before recovery, but its causal relationship to the splash is unconfirmed. The stdio closure reason contains the most recent stderr warning, which should not be treated as an independently established crash cause.
- Static frontend code uses the same blossom splash for multiple loading gates. Please inspect which frontend gate/query remains pending and why local app-server reconnection releases it.
- Please examine startup query invalidation, host selection (local vs durable), gateway readiness, Statsig readiness, and the codex_app MCP startup ordering. These are diagnostic questions, not established root causes.
This report intentionally excludes auth tokens, cookies, account identifiers, conversation contents and the complete user configuration. Raw logs have not been publicly uploaded.
补充现象：以管理员身份启动应用后，仍需手动结束 codex.exe 才能进入界面。进入后，相关问题已有回复，但输入框上方仍保留同一问题的待处理条目，没有自动消失。
随后完全退出应用，以普通方式重新启动，同样需要结束 codex.exe 才能进入。再次打开同一对话，该问题显示在聊天记录中，下方出现“你在 0 秒后停止了”。两次启动后，同一问题的任务显示状态不一致。
请检查启动挂起与后台重连是否影响消息队列和任务状态同步。管理员启动和普通启动均未解决启动问题。
What steps can reproduce the bug?
1.单击左键普通打开chatgpt桌面端。2.以管理员身份运行软件。
What is the expected behavior?
在已登录账号的情况下，从 Windows 开始菜单正常启动应用后，应在合理时间内完成初始化，显示完整的主页、侧栏和聊天内容，并能正常启动和执行 Codex 任务。关闭后再次打开也应正常进入，无需手动结束 codex.exe、重新登录账号或反复尝试启动。
Additional information
我通过在任务管理器里面关闭codex.exe文件之后会卡顿3s左右然后就进入大致正常的桌面端了，但是桌面端左侧功能键缺失。我通过断网然后重新连接网络，再进行重新登录账号，这时也可以进入软件，但是这次进入的是完整的桌面端，没有扫描缺失
Activity
github-actions commentedon Sep 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
carlsonlstout commentedon Sep 30, 2026
THIS FIXES THE ISSUE!!!!!!!!
Normal startup remains on a blank splash screen with a centered OpenAI logo. Previously it showed a spinner. The user can enter the UI by manually terminating the initial local codex.exe app-server; the desktop host starts another app-server and the UI appears. This is required even when the account was already signed in before application launch. Please do not interpret the initial process exit as a spontaneous crash: the user intentionally terminated it.
Leave the Codex window open.
Press Ctrl + Shift + Esc to open Task Manager.
Select Details on the left.
Right-click a column heading, such as Name, and choose Select columns.
Check Command line, then click OK.
Find a codex.exe process whose command line contains app-server. Widen the column if needed.
Right-click that specific process and choose End task—not “End process tree.”
i was able to access codex after stuck on splash screen for a week