›_ Codex Issues
Codex Issues / #33319

[app][macOS] Browser-use Node workers accumulate to 10–18 GB, exhaust swap, and suspend unrelated apps

Open 💬 1 comment Opened Jul 15, 2026 by yorwos

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.72221

What subscription do you have?

Pro

What platform is your computer?

_No response_

What issue are you seeing?

Summary

During long Codex desktop tasks involving browser testing and screenshots, multiple Node worker processes accumulate in the ChatGPT/Codex macOS resource coalition. Their combined footprint reaches approximately 10–18 GB, exhausting memory compression and available swap on a 16 GB Mac.

macOS then deliberately suspends unrelated applications—including Chrome, Excel, Calendar, Preview, Terminal and Activity Monitor—because of swap exhaustion. Applications that have already been suspended do not recover merely by closing ChatGPT. They must be force-quit individually, creating a risk of losing unsaved work.

In-app feedback

I submitted feedback from the affected Codex session. The full feedback/session ID has already been provided privately to OpenAI Support and can be supplied privately to an identifiable OpenAI maintainer on request.

I am intentionally withholding the ID from this public report because the affected session involved a private project.

Environment

  • Application: New unified ChatGPT desktop app with Codex
  • ChatGPT version: 26.707.72221
  • ChatGPT build: 5307
  • Bundled Codex version: codex-cli 0.144.2
  • Device: 15-inch MacBook Air
  • Model identifier: Mac15,13
  • Processor: Apple M3
  • Memory: 16 GB
  • macOS: 26.5.2
  • macOS build: 25F84
  • Available storage during incidents: approximately 40–50 GB

The bundled Codex binary is located at:

/Applications/ChatGPT.app/Contents/Resources/codex

There is no separate /Applications/Codex.app installation on this computer.

Reproduction pattern

The problem occurs repeatedly during a long autonomous Codex task on a local web application project.

The task asks Codex to:

  • Work autonomously for an extended period.
  • Test existing functionality.
  • Identify and fix verified defects.
  • Continue through multiple work items.
  • Perform browser checks and capture screenshots.
  • Update project handoff documents.
  • Deploy verified changes when appropriate.

Codex opens the in-app browser and performs repeated browser-based checks and screenshots.

I did not explicitly request subagents or parallel agents. I cannot determine whether Codex created additional agents or workers internally.

I have not yet completed a controlled browser-on versus browser-off comparison. However, every incident for which I have clear diagnostic evidence occurred while Codex was performing browser testing or capturing screenshots. Browser tooling is therefore strongly correlated with the failure, although I cannot yet prove that it is strictly required.

User-visible behaviour

macOS displays:

Your system has run out of application memory.

The Force Quit window then shows unrelated, low-memory applications in red and marked as paused. These have included:

  • Calendar
  • Terminal
  • Preview
  • Activity Monitor
  • Microsoft Excel
  • Google Chrome
  • ChatGPT

Some of these applications are using only tens or hundreds of megabytes.

Closing ChatGPT or freeing several gigabytes does not reliably restore applications that the kernel has already suspended. I must force-quit those paused applications individually before the computer becomes fully responsive.

Diagnostic evidence

macOS generated repeated JetsamEvent reports in which:

  • largestProcess was node.
  • The dominant Node processes shared the same macOS resource coalition as ChatGPT/Codex.
  • The memory displayed next to ChatGPT in the Force Quit window substantially understated the resource coalition’s complete Node footprint.
Incident: 14 July 2026 at approximately 09:52 BST
  • Free memory: approximately 61 MB
  • Compressed memory: approximately 12,862 MB
  • ChatGPT/Codex coalition: 34 processes
  • Aggregate coalition footprint: approximately 19,479 MB
  • Node workers in that coalition: approximately 18,068 MB
  • largestProcess: node
Incident: 14 July 2026 at approximately 10:01 BST
  • Free memory: approximately 31 MB
  • Compressed memory: approximately 11,467 MB
  • ChatGPT/Codex coalition: 33 processes
  • Aggregate coalition footprint: approximately 17,913 MB
  • Node workers in that coalition: approximately 16,567 MB
  • largestProcess: node
Incident on the current ChatGPT build: 14 July 2026 at approximately 19:52 BST
  • Free memory: approximately 54 MB
  • Compressed memory: approximately 12,285 MB
  • ChatGPT/Codex coalition: 36 processes
  • Aggregate coalition footprint: approximately 11,881 MB
  • Node workers in that coalition: approximately 10,199 MB
  • Largest individual Node workers: approximately 2,866 MB, 2,152 MB, 1,905 MB, 1,623 MB and 1,079 MB
  • largestProcess: node

Kernel evidence

The macOS unified log recorded the following events:

09:51:43 memorystatus: triggering no paging space action
09:51:43 memorystatus: suspending ChatGPT due to swap exhaustion
09:51:48 memorystatus: suspending Preview due to swap exhaustion
09:51:53 memorystatus: suspending Activity Monitor due to swap exhaustion
10:01:26 memorystatus: suspending Safari due to swap exhaustion
10:01:31 memorystatus: suspending Calendar due to swap exhaustion
10:01:36 memorystatus: suspending Terminal due to swap exhaustion
10:01:42 memorystatus: suspending com.apple.WebKit.GPU due to swap exhaustion
19:52:23 memorystatus: suspending Google Chrome due to swap exhaustion

This confirms that the low-memory applications are victims of the system-wide memory and swap exhaustion. They are not its original cause.

Microsoft Excel incident

During a separate incident, Microsoft Excel was the actively used foreground application.

The unified log recorded:

Microsoft Excel: hang likely: start
Microsoft Excel is unresponsive, hasn't responded for 56.8 seconds

Excel’s WebKit Networking and WebContent helpers then terminated. Excel itself was subsequently terminated with signal 9.

This demonstrates that the issue can hang or terminate an actively used foreground application and therefore creates a genuine risk of unsaved-work loss.

Why closing the large consumer does not immediately fix everything

Once macOS exhausts paging space, the kernel deliberately suspends selected applications. Those applications are no longer merely running slowly; their execution has been stopped.

Releasing memory afterward does not necessarily resume every already-suspended process. Suspended applications may also leave file-coordination or interprocess-communication requests waiting for responses, amplifying the apparent system freeze.

Force-quitting the suspended applications destroys those processes and releases their outstanding connections. This is why closing several small applications may be required even though they are not consuming significant memory.

Misleading memory attribution

The Force Quit window can show ChatGPT using only approximately 1–2 GB while macOS reports another 10–18 GB across Node workers in the same ChatGPT/Codex resource coalition.

This makes it difficult for the user to identify the real memory consumer. The complete descendant-worker footprint should be attributed to ChatGPT/Codex in the user interface.

Hardware and filesystem checks

I performed the following read-only checks:

  • SSD SMART status: Verified
  • Live APFS volume verification: Passed
  • No kernel panic reports found
  • Approximately 40–50 GB of storage available
  • No spontaneous restart or shutdown

The computer returns to normal after the affected processes are terminated. These findings point to application or worker-process resource exhaustion rather than defective hardware or a corrupt filesystem.

Expected behaviour

  • Browser and Node workers should be reclaimed after browser checks finish.
  • Codex should impose a reasonable aggregate memory limit on its complete process tree.
  • Codex should stop or warn before exhausting system swap.
  • Child-worker memory should be correctly attributed to ChatGPT/Codex.
  • Closing or completing browser tasks should terminate unnecessary browser and Node workers.
  • A Codex task should not cause macOS to suspend unrelated foreground applications.
  • Long tasks should degrade gracefully rather than causing a system-wide application-memory emergency.

Requested investigation

Please investigate:

  1. Whether in-app browser, screenshot, Node REPL, Playwright or related workers remain alive after browser checks complete.
  2. Why multiple individual Node workers grow to approximately 1–3 GB each.
  3. Whether long autonomous tasks repeatedly create workers without reclaiming previous ones.
  4. Whether internal agent or browser concurrency is contributing even when the user did not explicitly request subagents.
  5. Why ChatGPT’s displayed memory does not include the complete footprint of its Node workers.
  6. Whether Codex can enforce a configurable or automatic aggregate memory budget.
  7. Whether Codex can stop its work and warn the user before macOS reaches swap exhaustion.

Possibly related issues

  • #17257 — reports numerous Node and Playwright processes not being cleaned up
  • #19333 — Codex Mac app high memory usage
  • #20740 — Codex memory growth causing the macOS application-memory warning

This report adds:

  • macOS resource-coalition attribution
  • Exact aggregate Node footprints
  • Repeated JetsamEvent evidence
  • Kernel-confirmed swap exhaustion
  • Kernel-confirmed suspension of unrelated applications
  • Evidence of potential unsaved-work loss in an actively used application
  • Correlation with in-app browser checks and screenshots

Additional information

I can perform a short, controlled browser-on versus browser-off comparison if a maintainer requests it and specifies which process measurements would be most useful.

I have intentionally not attached local application logs or session transcripts because they contain private project information. I can provide specific redacted diagnostic fields as text or supply the in-app feedback ID privately to an identifiable OpenAI maintainer.

What steps can reproduce the bug?

see main issue above

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗