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

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

Version 26.908.40834

What subscription do you have?

pro

What platform is your computer?

No response

What issue are you seeing?

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

Summary

ChatGPT Desktop Local Work is completely unusable on my Mac.

Existing local threads fail to resume/open correctly, but importantly the problem also reproduces with a completely fresh CODEX_HOME and a brand-new Local Work thread.

In that clean environment:

1. Launch ChatGPT Desktop with a new empty CODEX_HOME
2. Create a new conversation
3. Select Work
4. Select Local
5. Enter run test
6. Press Send

The Send button spins indefinitely. The turn never starts.

Cloud Work continues to work normally.

Environment

• ChatGPT Desktop: 26.908.40834
• Desktop build: 8881
• Bundled Codex: 0.154.0-alpha.6.2
• macOS: 27.0 Golden Gate, build 26A428
• Hardware: Apple Silicon Mac Studio
• Account: ChatGPT Pro
• Region: UK
• Date reproduced: 14 September 2026

Expected behaviour

A new Local Work conversation should submit the first turn and begin execution.

Actual behaviour

The Send control enters an indefinite spinner state and no Local Work turn begins.

Existing Local Work conversations also fail to resume/open successfully.

Cloud Work conversations continue to operate normally.

Important clean reproduction

The issue reproduces against a completely new CODEX_HOME.

No existing:

• conversations
• SQLite databases
• MCP configuration
• skills
• plugins
• caches
• thread locks
• other ~/.codex state

were copied into the test environment.

This appears to rule out corruption or configuration in my normal ~/.codex as the cause.

Observed app-server behaviour

Desktop logs show the local app-server becoming saturated.

A recurring state is:

inFlightRequestCount=6

After this, unrelated app-server requests begin expiring while queued with:

App server request expired while queued

Affected RPCs include:

• thread/read
• thread/resume
• thread/list
• model/list
• config/read
• configRequirements/read
• skills/list
• plugin/installed
• mcpServerStatus/list

Eventually Local Work thread hydration/resume and message submission cannot proceed.

This appears similar to other reports of the bounded/shared app-server request pool becoming saturated.

Additional observations

The bundled plugin reconciliation process is active around the time the request queue begins to stall.

In particular, the logs repeatedly show the bundled sites plugin being considered missing and an installation being requested.

However, I have not established that bundled plugin reconciliation is the root cause. It may instead be another operation affected by the same underlying app-server blockage.

Disabling my user-configured MCP servers did not resolve the problem.

A process sample taken while the failure was occurring showed the bundled Codex process still alive rather than crashing.

Existing environment checks

Before establishing the clean reproduction, I also checked my normal environment.

Both databases pass SQLite integrity checks:

queue_1.sqlite:

PRAGMA quick_check; → ok

state_5.sqlite:

PRAGMA quick_check; → ok

I also tested:

• complete ChatGPT restart
• terminating the bundled Codex runtime
• terminating SkyComputerUseService
• checking thread writer locks
• removing an apparently stale writer lock
• resetting ChatGPT Desktop UI/profile state while preserving ~/.codex
• disabling user MCP servers
• completely fresh CODEX_HOME

None restored Local Work.

Why I think this may be related to existing issues

There appear to be several recent reports involving the same general failure mode:

• app-server reaches approximately six in-flight requests
• further RPCs accumulate
• requests expire while queued
• thread hydration/read/resume fails
• eventually interactive submission/turn/start cannot proceed

Related issues include:

• #40540
• #43122
• #37401
• #36914
• #36189
• #40968

There are also several current issues involving ChatGPT Desktop 26.908.40834 and bundled-runtime/session failures.

I am filing this separately because my reproduction has an important difference:

the failure occurs on the first turn of a completely new Local Work conversation using a completely fresh CODEX_HOME.

There is therefore no existing conversation/history hydration or migrated user configuration required to trigger it.

Possible regression boundary

The relevant combination is:

ChatGPT Desktop 26.908.40834 / bundled Codex 0.154.0-alpha.6.2 / macOS 27.0 build 26A428 / Apple Silicon

I have not established whether the regression is:

• Desktop 26.908.40834
• bundled Codex 0.154.0-alpha.6.2
• macOS 27 / 26A428
• bundled plugin/app-server initialisation
• or an interaction between them.

Impact

Severity: blocking

Local Work is completely unavailable.

This prevents use of local Work capabilities including local tools/computer interaction. Cloud Work still functions, but it is not a substitute for workflows requiring the local Mac environment.

Diagnostics available

I can provide:

• ChatGPT Desktop logs covering the failure
• Codex process sample captured during the stall
• exact clean CODEX_HOME reproduction steps
• additional app-server logging if maintainers specify what would be useful

I have preserved my original ~/.codex and have not deleted the affected local conversations.

Request

Could the Desktop/Codex team please:

1. Confirm whether this matches an existing app-server queue starvation issue.
2. Check whether the clean CODEX_HOME reproduction indicates a regression in 26.908.40834 / bundled 0.154.0-alpha.6.2.
3. Confirm whether macOS 27 build 26A428 is a known factor.
4. Advise if there is a supported feature flag or launch option that bypasses the component occupying the app-server request slots.
5. Identify a known-good Desktop build if rollback is currently the recommended workaround.

I am happy to run targeted diagnostics against the clean environment if that would help isolate which app-server requests are occupying the in-flight slots.

What steps can reproduce the bug?

.

What is the expected behavior?

.

Additional information

.

Reproduce the failure with a completely fresh CODEX_HOME using ChatGPT Desktop 26.908.40834 and bundled Codex 0.154.0-alpha.6.2, then inspect Desktop logs around inFlightRequestCount=6 and queued request expiry. Compare the app-server requests and bundled plugin reconciliation activity; done means a new Local Work thread submits its first turn without indefinite spinner or request starvation.