Skip to content

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

Open

Description

@ean7

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:

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

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    app-serverIssues involving app server protocol or interfaces
    on Aug 25, 2026
  2. Miles-Cheverton commented on Sep 14, 2026

    @Miles-Cheverton

    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_HOME had 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions