Repository navigation
[macOS Desktop] app-server grows to 20-28 GB during thread hydration; queued turns time out and runtime is SIGKILLed #40540
Description
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT desktop app 26.818.61809 (build 7019).
Bundled runtime:
codex-cli 0.149.0-alpha.4.3
What subscription do you have?
ChatGPT Pro.
What platform is your computer?
Apple Silicon Mac with 16 GB RAM.
macOS 13.7.8 (build 22H730)
arm64
What issue are you seeing?
Codex Desktop repeatedly enters an unbounded local app-server memory-growth and queue-starvation cycle. The runtime grows from a green baseline to 20-28 GB total memory, with 18-26 GB compressed memory, within approximately 3-6 minutes. macOS then accumulates tens of gigabytes of swap, app-server requests expire while queued, turn/start times out, composer submission fails, and the app-server may be terminated with SIGKILL.
The issue reproduced after:
- fully quitting and reopening the app;
- moving the work to a new small recovery chat that did not load the original long chat history;
- a full Mac reboot;
- limiting work to one visible light local task with no parallel heavy tasks.
Post-reboot memory timeline:
| UTC | PID | macOS available | Compressor | Swap | Runtime total / compressed | State |
|---|---|---|---|---|---|---|
| 03:30:45 | 751 | 90% | 0 MB | 0 MB | 142 / 0 MB | green |
| 03:33:02 | 751 | 35% | 8,274 MB | 5,340 MB | 9,565 / 7,363 MB | restart required |
| 03:35:51 | 751 | 34% | 8,160 MB | 31,048 MB | 24,576 / 22,528 MB | runaway |
| 03:40:59 | 3844 | 78% | 1,234 MB | 2,100 MB | 1,920 / 0 MB | temporary recovery |
| 03:46:04 | 3844 | 34% | 8,064 MB | 37,769 MB | 28,672 / 26,624 MB | runaway reproduced |
The desktop app log correlates the failure with background thread catalog/history hydration and local app-server queue starvation:
03:32:52 sidebar thread/read timed out
03:34:28 thread catalog request expired while queued
03:35:31 thread catalog request expired while queued
03:37:37 thread/list expired after ~60s, pending queue ~8
03:37:51 thread/list expired after ~60s, pending queue ~10
03:37:49-03:37:53 slow local log DB insert (92 rows, ~4.1s), then app-server transport closed with SIGKILL
03:47:25 thread/turns/list tail-history request expired, pending queue ~7
03:47:59 critical config request timed out, pending queue ~11
03:48:29 turn/start timed out, pending queue ~15, composer submit failed
03:48:52 turn/start timed out, pending queue ~16, composer submit failed
03:49:04 turn/start timed out, pending queue ~13, composer submit failed
Bounded log counts from the affected run:
- 22 queued app-server request expiry/timeout records;
- 11 thread catalog sync failures;
- 14
collab_hydrationrecords; - 11
tail_historyrecords; - 3 explicit
turn/starttimeouts; - 4 composer submit failures;
- 17 slow SQL statement alerts;
- 162 renderer
ResizeObserverloop errors; - 31 unique conversation IDs referenced by the app log.
This proves the local failure chain but does not establish which component starts it. Candidate areas are unbounded app-server retention during catalog/tail-history hydration, background request backpressure, local logging/database feedback, renderer error amplification, or an interaction among them.
What steps can reproduce the bug?
- Fully quit ChatGPT/Codex Desktop.
- Reboot a 16 GB Apple Silicon Mac.
- Open one local project and one small chat.
- Do not start parallel tasks, builds, renders, browser automation, or other heavy work.
- Observe an initially green runtime baseline.
- Leave the app open and use only the one light chat.
- Within approximately 3-6 minutes, observe rapidly increasing Codex runtime total/compressed memory and swap.
- Attempt to send another message.
- Observe
App server request expired while queued,turn/starttimeout, or composer submission failure. - Fully restart the app or Mac and observe that the cycle can reproduce with a new runtime PID.
What is the expected behavior?
- One idle/light local chat should remain responsive and memory should stabilize.
- Background catalog/history hydration should be bounded, cancellable and lower priority than interactive
thread/readandturn/startrequests. - A slow or abnormal thread should not block the global app-server queue.
- The app-server should not grow beyond physical RAM, create tens of gigabytes of swap, or require repeated process/Mac restarts.
- If memory or queue thresholds are exceeded, the app should stop background hydration and present a recoverable error instead of allowing host-wide degradation.
Additional information
Related reports:
- [Windows Desktop] Selected recent task stays blank while collaboration hydration starves app-server queue #36914 — collaboration hydration starves the app-server queue on Windows;
- [Codex App][Remote SSH] Thread hydration blocks the app-server queue and causes an endless reconnect loop #36189 — thread hydration blocks the queue in Remote SSH;
- Codex Desktop: composer submit times out after stale conversation state accumulates; restart clears it #23644 — macOS composer timeouts after stale conversation state accumulates;
- macOS desktop: primary window stuck on loading screen while tasks continue; New Window recovers but browser state is lost #37550 — macOS primary renderer issues with repeated
ResizeObservererrors.
This report is distinct because it captures repeatable macOS local-runtime memory growth to 20-28 GB, extreme compressed memory/swap pressure, queue starvation, and app-server SIGKILL after both a runtime restart and a full reboot.
Disk capacity remained ample, Chrome was materially smaller than the Codex runtime, and the behavior reproduced without Docker/VM or parallel heavy work. Raw logs, local paths, thread IDs and session transcripts are intentionally not attached because they may contain private information. Sanitized excerpts and timestamped metrics can be provided privately if requested.
Activity
github-actions commentedon Aug 25, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Miles-Cheverton commentedon Sep 14, 2026
Sharing a macOS recovery observation from #45405, which also involved queued app-server requests expiring and Local Work becoming unusable.
Turning Allow Connections OFF in ChatGPT Desktop, waiting a few seconds, then turning it ON again restored Local Work on my Mac Studio. Earlier app/runtime restarts, disabling user MCP servers and a fresh
CODEX_HOMEhad not restored it. I did not need to downgrade macOS.My environment is ChatGPT 26.908.40834 (8881), bundled Codex 0.154.0-alpha.6.2, macOS 27.0 build 26A428, arm64.
My failure also affected the first turn of a new Local Work conversation. I have not established the memory-growth/SIGKILL sequence described here or that the toggle fixes that defect. The recovery may nevertheless be useful to compare while investigating the shared queue symptoms. Full findings and attempted recovery steps: #45405.