ChatGPT Desktop: all Local Work hangs, including first turn with clean CODEX_HOME #45405

Activity

1. Miles-Cheverton

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 14, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Sep 14, 2026
3. github-actions commented on Sep 14, 2026

   

   github-actionsbot

   on Sep 14, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows Desktop] 26.903.8094.0 app-server queue blocks plugins and Remote Control; recent history omitted after restart #44401

   Powered by Codex Action
4. Miles-Cheverton commented on Sep 14, 2026

   

   Miles-Cheverton

   on Sep 14, 2026

   Author

   More actions

   Additional context after investigating related reports:

   This appears to belong to a broader cluster of Desktop local app-server/request-queue failures rather than being isolated to my existing local state.

   The particularly important aspect of this report is that I can reproduce it with a completely fresh CODEX_HOME on the first message of a brand-new Local Work conversation:

   new empty CODEX_HOME → new Work conversation → Local → "run test" → Send spins indefinitely

   Cloud Work continues to work.

   My normal-environment logs repeatedly reach:

   inFlightRequestCount=6

   followed by:

   App server request expired while queued

   with thread/read, thread/resume, thread/list, config/model/plugin/skills calls subsequently timing out.

   Related reports that appear potentially relevant include #40540, #43122, #37401, #36914, #36189 and #40968.

   There is also an older macOS report, #13715, where all local Codex clients hang on even trivial prompts while web continues to work.

   I have also opened an OpenAI Support case and supplied the clean-environment reproduction there.

   Happy to run a diagnostic build, collect targeted traces, or test a known-good/known-bad Desktop build if that would help identify the regression boundary.
5. Miles-Cheverton commented on Sep 14, 2026

   

   Miles-Cheverton

   on Sep 14, 2026

   Author

   More actions

   Additional concrete reproduction/error
   I have now obtained an explicit error when attempting to open/resume one of the affected Local Work conversations:
   Failed to resume chat
   paginated threads do not support initialTurnsPage; use turnsBackwardsCursor and itemsBackwardsCursor
   This appears potentially significant because it suggests the Desktop client is attempting to resume a paginated local thread using initialTurnsPage, while the bundled app-server expects the cursor-based turnsBackwardsCursor / itemsBackwardsCursor API.
   Environment remains:
   ChatGPT Desktop 26.908.40834
   bundled Codex 0.154.0-alpha.6.2
   macOS 27.0 / 26A428
   This may also help explain the thread/resume failures and subsequent app-server request queue starvation reported above.
6. Miles-Cheverton commented on Sep 14, 2026

   

   Miles-Cheverton

   on Sep 14, 2026

   Author

   More actions

   Update — recovery found on 14 September 2026; underlying cause still unconfirmed

   I lost an entire working day to this failure and the troubleshooting. Local Work is now working again after the recovery below.

   What restored Local Work

   On 14 September 2026, turning Allow Connections OFF and then ON again in ChatGPT Desktop on the affected Mac Studio unblocked Local Work. I reported the recovery at 15:55:49 BST (14:55:49 UTC) and confirmed at 15:56:48 BST (14:56:48 UTC) that local Work sessions were working normally.

   Recovery procedure: on the affected Mac, open ChatGPT Desktop, turn Allow Connections off, wait a few seconds, turn it on again, and test a Local Work conversation.

   This is an observed workaround on my machine. I have not established which internal component it resets, whether it is a permanent fix, or whether it applies to other operating systems. I did not downgrade macOS to obtain this recovery.

   Environment and comparison machine

   	Affected Mac Studio	Working MacBook Air
   Architecture	arm64	arm64
   macOS	27.0, build 26A428	27.0, build 26A5425a
   ChatGPT Desktop at final comparison	26.908.40834 (8881)	26.908.40834 (8881)
   Bundled Codex	0.154.0-alpha.6.2	0.154.0-alpha.6.2

   The same account worked on the Air while the Studio failed. Cloud Work continued to work. The OS-build difference was an investigative lead, not proof that 26A428 caused the failure: the Studio recovered without changing its OS build.

   Failure and reproduction

   Existing Local Work conversations would not open or resume properly. The failure also affected the first turn of a completely new Local Work conversation:

   1. Launch Desktop with a new empty CODEX_HOME, without copying normal configuration, conversations or databases.
   2. Create a new conversation and select Work → Local.
   3. Enter run test and press Send.
   4. The Send button spins indefinitely and execution never begins.

   I reported that clean-home test failing at about 11:28 BST. Later, a launch using both a fresh temporary CODEX_HOME and a separate --user-data-dir also failed. These are the tests performed; I have not independently proved that every Desktop service honoured those directory overrides.

   Diagnostics

   • Desktop logs showed inFlightRequestCount=6 and App server request expired while queued.
   • The affected methods recorded in the initial report included thread/read, thread/resume, thread/list, model/list, config/read, configRequirements/read, skills/list, plugin/installed and mcpServerStatus/list.
   • Later captured requests repeatedly showed thread/read and thread/resume while the composer was spinning, without a turn/start appearing in that capture.
   • The bundled app-server remained alive in process samples. Waiting stacks were observed; that alone does not prove deadlock or explain the occupied request slots.
   • Both queue_1.sqlite and state_5.sqlite returned ok from PRAGMA quick_check before the database experiments. This establishes the check results, not that every stored item or protocol interaction was correct.
   • Bundled plugin reconciliation, particularly repeated attempts to install sites, appeared around the stalls. This remains a correlation.
   • Resuming through the bundled CLI also stalled at model: loading / Resuming session…. Merely opening the CLI did not demonstrate a working backend.
   • Other errors seen during troubleshooting included paginated threads do not support initialTurnsPage; use turnsBackwardsCursor and itemsBackwardsCursor, and an Air-to-Studio error containing unknown variant 'functionCallOutput'. The latter was encountered while the Studio was on the rollback build, so version mismatch is a possible confounder.

   What we tried before the successful toggle

   These are historical attempts and outcomes, not recommendations to repeat invasive changes.

   Attempt	Outcome
   Full Desktop restarts, terminating bundled Codex and the Computer Use helper	Did not restore Local Work.
   Reboot the Mac Studio	Failure persisted.
   Inspect writer locks; move an apparently stale LinkedIn task lock aside	No improvement.
   Resume the affected conversation with bundled CLI	Stalled while loading/resuming.
   Reset Desktop UI/profile state while preserving normal Codex data	No improvement; exact legacy folders present at the time were not fully established.
   Temporarily block user MCP servers through a requirements policy	No improvement; this did not prove bundled plugin reconciliation was disabled. Temporary policy was subsequently removed/restored.
   Disable both apps and plugins through feature flags	No improvement. These overrides were subsequently removed.
   New empty CODEX_HOME	Fresh Local first turn still hung.
   Fresh CODEX_HOME plus separate Desktop data directory	Same result.
   Quarantine the LinkedIn rollout	No improvement; restored.
   Change stored history_mode from paginated to legacy	No improvement. After an overly broad reverse edit, state_5.sqlite was restored from the 10:26 backup. This was not the fix.
   Roll Desktop back from 26.908.40834 to 26.810.52044	Rollback version explicitly verified; fresh Local test still failed. Later returned to 26.908.40834.
   Sign out and back in	Could not complete sign-out; not a completed test.
   Move Desktop application-support state aside, including a later test of the Codex support directory	No improvement; the later Codex directory change was restored.
   Connect from the working MacBook Air to the Studio	Temporarily restored operation around 14:10 BST; Local Work failed again around 14:35 and 14:42.
   Kill only the app-server and allow Desktop to respawn it	No improvement.
   Remove a malformed Nirvana MCP configuration	Subsequent logs reported all ten remaining MCP servers available, but Local Work still hung. This separate configuration correction was retained.
   Quarantine a different rollout reported as missing SQLite metadata	No improvement; restored.
   Move generated plugin/marketplace/cache directories aside to regenerate	No improvement.
   Try an external Codex CLI via CODEX_CLI_PATH	Initial path selected an older 0.147.0 binary; corrected to the installed 0.154.0 binary and retested, still no improvement. The override was then unset.
   Roll macOS back or create a new macOS user	Considered, not performed.
   Allow Connections OFF → ON on the Mac Studio	Local Work recovered, then I confirmed local sessions worked normally.

   What this now suggests

   Host connection state is a useful lead because both connecting from another Mac and toggling Allow Connections affected the behaviour. That does not establish whether the cause is registration, transport, request scheduling, remote-control state, a Desktop bug or an OS interaction.

   Please keep the underlying defect under investigation. A recovery toggle does not establish that it will stay fixed, and the earlier Air-assisted recovery was temporary. The useful next step is to identify what Allow Connections resets and compare the app-server/host state immediately before and after that action.

   Please also distinguish this report from database-corruption, renderer-crash and pagination-only issues: my clean first-turn failure and the eventual host-setting recovery need an explanation of their own.
7. Miles-Cheverton commented on Sep 17, 2026

   

   Miles-Cheverton

   on Sep 17, 2026

   Author

   More actions

   Update after installing ChatGPT Desktop 26.911.61220: Local Work is now working normally again on the same Mac. All of my previous Local Work threads have reappeared and are usable, and nothing appears to have been lost. I did not need to recreate threads, migrate data, or reset Local Work history. For me the regression boundary is: previous desktop build broken / requests stalled; 26.911.61220 working normally with all old threads restored. I can't confirm whether this build intentionally contains the fix, but it has completely resolved the problem on my machine so far.