›_ Codex Issues
Codex Issues / #36971

macOS Codex Desktop runaway task worker and app-server consume 12+ GB RAM with sustained high CPU

Open 💬 3 comments Opened Aug 4, 2026 by bt1142msstate
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop on macOS developed sustained runaway memory and CPU usage during ordinary local task work. A task worker reached approximately 5.5 GB RSS, while codex app-server subsequently remained around 7.0–7.3 GB RSS with 160–200% CPU. The app became slow and unstable.

This resembles #14666 and #21134, but this report includes a separately observed runaway cua_node/bin/node ... kernel.js task worker plus app-server retention after that worker was terminated.

Environment

  • Codex Desktop: 26.727.51351 (build 6119)
  • Bundled codex CLI: 0.146.0-alpha.9.2
  • macOS: 26.5.2 (25F84)
  • Architecture: arm64
  • Mac model: Mac16,10
  • Unified memory: 24 GiB
  • Chrome extension installed and enabled; Chrome/Computer Use workflows had been used
  • Multiple normal local tasks were present

Observed behavior

Three samples taken several seconds apart showed:

  • A child task worker, cua_node/bin/node ... kernel.js, sustaining roughly 57–95% CPU and growing from about 2.6 GB to 5.5 GB RSS.
  • codex app-server simultaneously sustaining roughly 130–166% CPU and using roughly 1.1–4.0 GB RSS.
  • System-wide free memory fell to about 44%.

I sent SIGTERM only to the runaway task worker. It exited cleanly and free memory rose immediately from about 44% to 71%, confirming that it was a material source of pressure.

However, app-server then retained/grew to approximately 6.9–7.3 GB RSS and sustained 158–204% CPU across four additional samples. Sending SIGTERM to app-server caused it to respawn, and system-wide free memory recovered to roughly 79%, although the newly spawned service and Electron processes briefly rebuilt several gigabytes of state.

Expected behavior

  • Completed, cancelled, or idle task workers should release their memory and terminate.
  • app-server should not retain several gigabytes of task state or peg multiple CPU cores after a task worker exits.
  • Long-running or tool-heavy tasks should have bounded local memory growth.
  • The app should expose a safe way to identify and reclaim stuck workers without restarting active tasks.

Reproduction pattern

No single deterministic action is known. The failure occurred after using Codex Desktop normally for multiple local tasks, including browser/computer-use capable workflows, and leaving the app running for about an hour. Memory and CPU grew until the UI became slow.

Recovery performed

  1. Confirmed sustained use across multiple process samples.
  2. Terminated only the 5.5 GB task worker.
  3. Confirmed immediate system memory recovery.
  4. After app-server remained near 7 GB and 160–200% CPU, terminated only app-server.
  5. app-server respawned and overall memory pressure returned to healthy levels.

No Chrome tabs, plugins, or user files were deleted. No raw session transcript or sensitive project data is attached.

Related issues

  • #14666
  • #21134
  • #11324

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 23 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35994
  • #36431
  • #35750

Powered by Codex Action

Haobook · 23 days ago

Additional report on the same Codex Desktop build:

  • Hardware: MacBook Air with Apple M2 and 8 GB unified memory
  • Codex Desktop: 26.727.51351
  • Platform: macOS (exact OS version was not captured)
  • Workload: reviewing a single local Markdown study note; no Computer Use or multi-agent workflow was requested
  • macOS displayed the application-memory warning and asked the user to terminate processes
  • Codex was reported at approximately 10 GB of memory usage
  • Quitting Codex immediately returned the system to normal
  • The process snapshot was no longer available after relaunching the app

This suggests the runaway-memory behavior in 26.727.51351 can also occur during a lightweight local Markdown review, rather than only during explicit Computer Use or heavy project workflows.

negentropi · 23 days ago

Additional same-build report with heap-level diagnostics

I reproduced a more extreme form of the runaway-memory behavior on the same app build.

Environment

  • ChatGPT/Codex macOS app: 26.727.51351 (build 6119)
  • macOS: 26.4 (25E5223i)
  • Architecture: Apple Silicon / ARM64
  • Unified memory: 32 GB
  • Backend process: /Applications/ChatGPT.app/Contents/Resources/codex
  • Parent process: ChatGPT
  • Backend launch time: August 1, 2026 at 2:19:38 PM +0800
  • Diagnostics captured: August 5, 2026 at approximately 3:04–3:09 PM +0800

Observed behavior

Activity Monitor showed:

  • codex: approximately 21.08 GB memory
  • System swap used: 44.51 GB
  • Compressed memory: 11.27 GB
  • Yellow memory pressure

sample reported:

Physical footprint:         21.4G
Physical footprint (peak):  21.4G

vmmap -summary showed that the footprint was overwhelmingly native heap allocation rather than mapped files, stacks, or allocator fragmentation:

Writable regions: Total=23.4G written=19.7G resident=39.2M swapped_out=21.2G
MALLOC_SMALL: 22.2G total, 20.8G swapped out
mapped file: 34.6M
Stack: 632.2M total, 10.9M swapped out

Default malloc zone:
- Zone size: 22.6G
- Allocation count: 122,875,395
- Bytes allocated: 20.1G
- Fragmentation: 1.1G / 6%

This looks like severe unbounded retention of a very large number of small native allocations. The 6% fragmentation figure makes allocator fragmentation an insufficient explanation for the approximately 20.1 GB of allocated heap content.

Sampled activity

The CPU sample included repeated activity in or around:

  • codex_tools::code_mode::code_mode_tool_definitions_for_spec
  • codex_core::mcp_tool_exposure::build_mcp_tool_runtimes
  • codex_tools::mcp_tool::parse_mcp_tool
  • codex_tools::json_schema::parse_tool_input_schema
  • serde_json serialization/allocation paths
  • multiple sqlx-sqlite-worker-* threads

This is only CPU-stack evidence and does not establish which path owns the retained 20.1 GB.

Reproduction pattern

No deterministic single action is known. This occurred after leaving the app running for approximately four days during normal Codex use. The process retained the 21.4 GB footprint at capture time, with 21.2 GB of writable memory already swapped out by macOS.

Expected behavior

Long-running Codex use should have bounded backend memory growth. Completed or idle task, tool-schema, MCP, session, and database state should be released or evicted rather than accumulating tens of gigabytes.

Public-data safety

The diagnostic excerpts contain no prompts, conversation content, repository paths, home-directory paths, command-line arguments, environment variables, credentials, tokens, email addresses, URLs, or network endpoints. Process identifiers, raw addresses, and binary UUIDs were removed from the public copy.

I have full sanitized sample and vmmap text available. The full sample is approximately 500 KB, so I omitted it from this comment and included the allocation-level findings above.