[macOS] Desktop shows false Thinking state with zero reasoning events until restart

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

ChatGPT desktop 26.908.40834 (build 8881); bundled Codex 0.154.0-alpha.6.2

What subscription do you have?

ChatGPT subscription (exact tier not exposed to the diagnostic process)

What platform is your computer?

Darwin 25.3.0 arm64 arm (macOS 26.3.2)

What issue are you seeing?

A newly created Codex task was marked started and the UI remained in a Thinking state, but its rollout produced no reasoning, assistant-message, token-count, or tool-call events for about 11 minutes.

Timeline (Asia/Shanghai, 2026-09-14):

• 20:01:18: task_started recorded.
• Until 20:12:40: no model or tool events were produced for the turn.
• 20:05:41: macOS repeatedly reported that main-thread work could cause UI unresponsiveness.
• 20:07:06: the old desktop process exited.
• 20:07:37: the new desktop process and app-server started.
• 20:12:40: the session resumed.
• 20:12:44: assistant output appeared in about three seconds.

From the user side, the task appeared to be thinking extremely slowly while showing no reasoning progress. Restarting the app restored normal behavior.

What steps can reproduce the bug?

The trigger is intermittent, but the observed conditions and recovery were:

1. Keep several long-running Codex tasks active.
2. At least one active rollout has grown to multiple gigabytes.
3. Create a new local Codex task and submit a prompt.
4. Observe that the task is marked started and the UI displays Thinking, while no reasoning, token-count, assistant-message, or tool-call event is written.
5. Fully quit and restart the desktop application.
6. Resume or resend the prompt; output begins normally within a few seconds.

The affected session ID is intentionally omitted from this public report because the session contains private local project context. Targeted redacted evidence can be provided.

What is the expected behavior?

• The UI must not show an indefinite Thinking state when no model turn is progressing.
• A stalled dispatch or event path should be detected and surfaced with an actionable retry or reconnect state.
• Large concurrent histories should not block desktop main-thread processing or event rendering.
• The task should recover without requiring a full application restart.

Additional information

Additional evidence:

• Four Codex tasks were active during diagnosis.
• Three other active rollout files were approximately 3.32 GB, 407 MB, and 39 MB and were still receiving events.
• After restart, macOS logged a potentially harmful notification post rate of 72.2169 notifications/second.
• The bundled app-server emitted a burst of FSEvents purge errors while rebuilding state.
• Related reports: #25009, #33153, and #44079. This occurrence adds macOS main-thread diagnostics, zero reasoning events after task_started, a high notification rate, and multi-gigabyte active rollouts.

No complete session logs are attached because they contain private local paths and project context. Targeted redacted excerpts can be provided if requested.

Start with related reports #25009, #33153, and #44079, then inspect the desktop app and bundled app-server around task_started, rollout event delivery, and restart recovery. Use targeted redacted evidence to compare the zero-event stall with the macOS main-thread and large-rollout diagnostics. Done means a stalled task is detected and offers recovery without requiring a full app restart.