›_ Codex Issues
Codex Issues / #27164

Codex Desktop: runaway memory/swap during Computer Use dev task on macOS (M4/16GB)

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

Environment

  • MacBook Pro (Apple Silicon M4), 16GB RAM
  • macOS (June 2026)
  • Codex Desktop (Computer Use enabled)
  • ChatGPT Atlas also running

Summary

Codex Desktop regularly enters a runaway memory state during Computer Use tasks (often involving a Next.js dev server / localhost preview). The system shows “Your system has run out of application memory”, memory pressure goes red, swap grows to tens of GB, and the machine becomes unusable / crashes.

Symptoms observed

  • Codex process memory reported as high as ~71.8 GB
  • Swap used grew to ~38.8 GB with red memory pressure
  • Activity Monitor became inconsistent (showed impossible values like 0 bytes physical memory while swap remained very large)
  • Kernel panic logs referenced Codex (Service) during the failure

Steps to reproduce (approx)

  1. Launch Codex Desktop.
  2. Run a Coding Task/Goal with Computer Use that involves running a local dev server (e.g., Next.js on localhost:3000) and browser interaction/preview.
  3. Continue working; memory pressure escalates and swap usage climbs rapidly.
  4. System becomes extremely sluggish and eventually crashes / requires forced restart.

Notes

  • Resetting Codex local state/caches temporarily reduces memory usage, but the issue returns once running Computer Use tasks again.
  • Happy to provide panic logs, screenshots, and exact timeline if helpful.

Expected

Memory usage stays bounded and released after tasks complete; no runaway swap growth or system instability.

Actual

Memory leak/runaway state triggers massive swap usage and system instability/crashes.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26738
  • #26458

Powered by Codex Action

BravoNiceCatch · 29 days ago

Additional macOS reproduction: an in-app Three.js/WebGL preview drives the Codex GPU service to 25–84 GiB

I have an independent reproduction that appears to be in the same failure family as this issue and also connects it to the in-app Three.js/WebGL compositor report in #24561.

Environment
  • ChatGPT/Codex Desktop: 26.721.81911 (build 5973)
  • macOS 15.7.4 (24G517), Apple Silicon
  • MacBook Pro MacBookPro17,1, Apple M1, 16 GB RAM
  • Trigger page: a local Vite + Three.js preview at http://127.0.0.1:5173/?qa=1
  • Page used THREE.WebGLRenderer, EffectComposer, UnrealBloomPass, and a continuous RAF render loop

No task/conversation IDs, local paths, raw panic files, or transcript contents are included below.

First failure and panic correlation

Local time is UTC+8.

09:43:15  The newly created active IAB guest reports dom-ready for
          http://127.0.0.1:5173/?qa=1
09:45:54  The machine becomes unresponsive and reboots with a kernel
          watchdog panic under exhausted compressor/swap pressure

The panic process snapshot showed approximately:

Codex/ChatGPT coalition total        86.84 GiB
one Codex (Service) process         83.73 GiB
separate Google Chrome coalition     2.19 GiB

The 83.73 GiB Codex (Service) process is unambiguously the embedded Chromium GPU process. Its thread names include:

CrGpuMain
GpuWatchdog
VizCompositorThread
CVDisplayLink
Chrome_ChildIOThread

Other Codex services, the main process, renderers, and app-server were all far smaller in the same snapshot. This was not the model/backend process and was not explained by the separate system Chrome process group.

Independent post-restart spike

After reboot I sampled all Codex processes and VM/swap state every five seconds. A later manual open/reload of the same IAB Three.js preview produced this transient event:

10:46:25  GPU Codex (Service) ~534 MiB; swap used 4.114 GiB
10:46:38  GPU Codex (Service) ~25 GiB;  swap used 17.613 GiB
10:46:45  GPU Codex (Service) ~777 MiB; swap used 9.121 GiB

So the allocation was short-lived, but it created real system pressure: swap grew by about 13.5 GiB within one sampling interval. This rules out the entire observation being only a harmless virtual-address reservation or an Activity Monitor display anomaly.

A later vmmap -summary of that same GPU service reported:

current physical footprint        588.7 MiB
physical footprint peak            50.8 GiB
Memory Tag 253 virtual region       48.0 GiB

Chromium's allocator source maps macOS VM tag 253 to kPartitionAlloc:
https://chromium.googlesource.com/chromium/src/+/f673a07393abb644b28575e8c8cac9052a44183e/base/allocator/partition_allocator/src/partition_alloc/page_allocator.h

The release build does not expose a usable historical PartitionAlloc allocation stack after the spike has been freed, so I cannot identify the exact Chromium C++ call site from the existing artifacts.

What this narrows down
  • The immediate runaway process is the shared embedded Chromium GPU process, not codex app-server, the model/backend, or ordinary system Chrome.
  • The strongest correlated trigger is activation/reload of a visible IAB WebGL page.
  • By the later reproduction the preview had already been constrained to a single RAF/context, 1280×720, DPR 1, and explicit WebGL/post-processing cleanup. A controlled preview stayed below roughly 1 GiB, while the visible/manual IAB activation produced the transient spike.
  • That makes the IAB guest/compositor/WebGL surface path—potentially visible-sidebar resize/render-target churn or retained GPU allocations—a stronger suspect than tab count alone.
  • The older HMR/RAF cleanup issue was real and could amplify pressure, but it does not fully explain the later fresh-page spike.
Suggested areas to inspect
  1. Per-IAB WebContents GPU-memory accounting and guest attach/detach lifecycle.
  2. Visible sidebar resize/compositor surface recreation, including IOSurface and WebGL render-target churn.
  3. PartitionAlloc/MemoryInfra traces around IAB activation and reload.
  4. A GPU-process memory-pressure guard that destroys or isolates the offending IAB guest before it can exhaust the entire machine.

This appears to add a process-level mechanism and a timestamp-correlated second reproduction to this report. Sanitized monitor excerpts and panic-derived aggregate fields can be provided if maintainers have a safe upload path.

tez4 · 11 days ago

<!-- markdownlint-disable MD041 MD036 -->
Same crash here, six occurrences across two days (Aug 16–17), all with an identical signature.

Environment

  • ChatGPT app 26.810.52044 (build 6662), bundle com.openai.codex, Chromium base 151.0.7922.137
  • macOS 26.5.1 (25F80), MacBook Pro M-series (Mac17,9), 64 GB RAM

Crash signature

SIGABRT (abort() called) out of node::OOMErrorHandler in the Codex Framework, so the embedded Node/V8 runtime is hitting its internal JS heap limit, not system memory (the machine has 64 GB and no memory pressure at crash time). The faulting thread is named computer-use in some crashes and V8Worker in others, and every stack contains parse_distilled_html frames:

__pthread_kill
pthread_kill
abort
node::OOMErrorHandler(char const*, v8::OOMDetails const&)
reading_mode$cxxbridge1$194$parse_distilled_html

Crashes happen during Computer Use / browser tasks, which matches the runaway-memory reports above. Ruled out on my side: no ~/.git at the home level (the trigger in #26884), and trimming ~/.codex local state reduces the baseline but doesn't address the parser path that aborts.

Also worth noting: the app's Crashpad uploader has never successfully uploaded any of these crashes (all sitting in pending/, zero in completed/), so you likely aren't seeing this crash volume in telemetry.