You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Infinite loading on launch with Windows 10 / OpenAI.Codex 26.924.2738.0 #49182
Windows 10 / OpenAI.Codex 26.924.2738.0에서 실행 시 무한 로딩됩니다.
재부팅, Windows 앱 복구·초기화, 웹 프로필 분리 후에도 동일합니다.
doctor에서 DB·스레드 목록·연결 검사는 정상이며, 앱 로그에서는 app-server 초기화 성공 후 app_start가 약 123초 만에 timeout으로 실패합니다. doctor는 26.924.6891.0 업데이트를 표시하지만 Microsoft Store와 winget에서는 업데이트가 없다고 나옵니다.
changed the title [-]Windows 10 / OpenAI.Codex 26.924.2738.0에서 실행 시 무한 로딩[/-][+]Infinite loading on launch with Windows 10 / OpenAI.Codex 26.924.2738.0[/+]on Sep 29, 2026
The app loads indefinitely when launched on Windows 10 / OpenAI.Codex 26.924.2738.0.
The issue persists after rebooting, repairing and resetting the Windows app, and separating the web profile.
In doctor, the DB, thread list, and connection checks all pass. However, the app logs show that after app-server initializes successfully, app_start fails with a timeout after approximately 123 seconds. doctor shows an update to 26.924.6891.0, but Microsoft Store and winget report that no updates are available.
The issue still occurs on Windows 10 after updating to OpenAI.Codex 26.928.1915.0. The installed package reports Status: Ok. The entire app remains on a black splash screen with the OpenAI logo; no sidebar or message composer appears.
Troubleshooting completed without recovery:
Windows app repair and reset
Updating with the latest installer
Restarting only the renderer (no momentary recovery)
Minimizing the app for 10 seconds and restoring it
Recent app-log observations:
Local executor rendezvous succeeds.
config/read, thread/list, and some thread/read requests succeed.
Authentication and Orbit requests return HTTP 200.
The codex-home entry reports hostId=undefined.
fs/readFile returns error -32602 requiring an environmentId.
The durable WebSocket handshake succeeds.
Some cloud thread/read requests are followed by "Conversation state not found".
These are observations only; I have not established the root cause, and these errors do not establish that local conversations have been lost.
A copied backup of the local Codex data directory exists. Its completeness, database integrity, and restorability have not been verified.
Could you provide a fixed build or a supported, safe workaround that preserves local-only conversations, attachments, and project mappings? Before any further destructive reset, data-directory deletion, or reinstall procedure, I need specific official guidance on what to back up and how to restore it. Please also clarify whether the environmentId/hostId and conversation-state errors above are relevant to the startup failure.
One additional observation: I have fully exited the desktop app from my perspective, but through Remote on my iPhone I can still open and use conversations that previously appeared only on the PC. Remote reports that only the app window was closed, which conflicts with the shutdown state I observe on the PC.
There is no obvious app icon in the taskbar or expanded system tray. This is a UI observation, not a process inventory; I have not verified that every background process or service has stopped.
Could you explain the expected background-process lifecycle after exiting the desktop app, why Remote can still access these conversations, and whether this apparent state mismatch could be related to the black-logo startup failure? Please advise on a supported recovery path that preserves the existing conversations and attachments.
Activity
[-]Windows 10 / OpenAI.Codex 26.924.2738.0에서 실행 시 무한 로딩[/-][+]Infinite loading on launch with Windows 10 / OpenAI.Codex 26.924.2738.0[/+]github-actions commentedon Sep 29, 2026
English translation:
The app loads indefinitely when launched on Windows 10 / OpenAI.Codex 26.924.2738.0.
The issue persists after rebooting, repairing and resetting the Windows app, and separating the web profile.
In doctor, the DB, thread list, and connection checks all pass. However, the app logs show that after app-server initializes successfully, app_start fails with a timeout after approximately 123 seconds. doctor shows an update to 26.924.6891.0, but Microsoft Store and winget report that no updates are available.
ChatGPT-startup-log.txt
Codex-diagnostics.json
github-actions commentedon Sep 29, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
exceedbuzz commentedon Sep 30, 2026
Update (September 30, 2026)
The issue still occurs on Windows 10 after updating to OpenAI.Codex 26.928.1915.0. The installed package reports Status: Ok. The entire app remains on a black splash screen with the OpenAI logo; no sidebar or message composer appears.
Troubleshooting completed without recovery:
Recent app-log observations:
These are observations only; I have not established the root cause, and these errors do not establish that local conversations have been lost.
A copied backup of the local Codex data directory exists. Its completeness, database integrity, and restorability have not been verified.
Could you provide a fixed build or a supported, safe workaround that preserves local-only conversations, attachments, and project mappings? Before any further destructive reset, data-directory deletion, or reinstall procedure, I need specific official guidance on what to back up and how to restore it. Please also clarify whether the environmentId/hostId and conversation-state errors above are relevant to the startup failure.
exceedbuzz commentedon Sep 30, 2026
One additional observation: I have fully exited the desktop app from my perspective, but through Remote on my iPhone I can still open and use conversations that previously appeared only on the PC. Remote reports that only the app window was closed, which conflicts with the shutdown state I observe on the PC.
There is no obvious app icon in the taskbar or expanded system tray. This is a UI observation, not a process inventory; I have not verified that every background process or service has stopped.
Could you explain the expected background-process lifecycle after exiting the desktop app, why Remote can still access these conversations, and whether this apparent state mismatch could be related to the black-logo startup failure? Please advise on a supported recovery path that preserves the existing conversations and attachments.