[macOS Desktop] app-server grows to 20-28 GB during thread hydration; queued turns time out and runtime is SIGKILLed

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_hydration records;
• 11 tail_history records;
• 3 explicit turn/start timeouts;
• 4 composer submit failures;
• 17 slow SQL statement alerts;
• 162 renderer ResizeObserver loop 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?

1. Fully quit ChatGPT/Codex Desktop.
2. Reboot a 16 GB Apple Silicon Mac.
3. Open one local project and one small chat.
4. Do not start parallel tasks, builds, renders, browser automation, or other heavy work.
5. Observe an initially green runtime baseline.
6. Leave the app open and use only the one light chat.
7. Within approximately 3-6 minutes, observe rapidly increasing Codex runtime total/compressed memory and swap.
8. Attempt to send another message.
9. Observe App server request expired while queued, turn/start timeout, or composer submission failure.
10. 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/read and turn/start requests.
• 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:

• #36914 — collaboration hydration starves the app-server queue on Windows;
• #36189 — thread hydration blocks the queue in Remote SSH;
• #23644 — macOS composer timeouts after stale conversation state accumulates;
• #37550 — macOS primary renderer issues with repeated ResizeObserver errors.

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.