›_ Codex Issues
Codex Issues / #11523

Feature request: Global memory budget and proactive OOM protection for Codex CLI

Resolved 💬 3 comments Opened Feb 12, 2026 by triplewhopper Closed Feb 12, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

CLI (multiple concurrent Codex instances on macOS)

What feature would you like to see?

Problem

In my environment, running multiple Codex CLI sessions with heavy Python workloads led to severe memory pressure and eventually a watchdog reboot.

Host/system where this occurred:

  • Apple M4 Pro, 14 CPU cores (10P+4E)
  • 48 GB RAM
  • macOS 26.2 (25C56)
  • Darwin kernel 25.2.0

Requested feature (proposal)

Could Codex consider first-class memory governance, ideally per-session and optional global?

  1. Budget settings (examples, not fixed API names):
  • e.g., a configurable per-session memory ceiling (via CLI flag and/or config key)
  • e.g., an optional shared/global budget across concurrent Codex sessions for one user
  1. Proactive behavior before host instability:
  • soft-threshold warnings
  • hard-threshold action (pause/deny new tasks, then terminate child tree gracefully with force-kill fallback)
  1. Visibility:
  • periodic RSS summary for Codex + descendants
  • explicit in-session notice when a process is terminated by policy
  • optional JSONL event log

Why this might help

In this incident, OS-level OOM handling did not recover in time. Failing fast at the Codex level could reduce host-level instability.

Additional information

Observed incident details:

  • Date/time: Feb 12, 2026 around 09:20 local time
  • Symptom: UI fully unresponsive (including trackpad), then automatic reboot
  • Panic/reset indicators: watchdog timeout / wdog reset path
  • During pre-panic window: sustained VM/compressor pressure and memorystatus kill activity, but recovery still failed

Current workaround:

  • external guard script that monitors aggregate RSS across all Codex process trees and enforces a memory limit

Related context:

  • no native memory-limit flag currently exposed in Codex sandbox settings on macOS
  • I searched related issues and found similar memory/OOM reports, but not an exact match for native global memory budgeting + in-session over-limit notification.

Tone/intent:

  • this is feedback based on one real incident, not a demand
  • I understand cross-platform resource policy is complex
  • I am happy to test proposed behavior and provide reproducible data if helpful

View original on GitHub ↗

3 Comments

etraut-openai contributor · 6 months ago

Can you say more about how you're using codex? Arte you running the non-interactive codex exec for automation use cases?

Do you suspect that the codex process was the one that was consuming the majority of the memory, or was the memory pressure mainly due to the Python workloads (which presumably instantiate codex)?

We have received reports of memory/OOM issues, but they are typically associated with the IDE Extension or app, not the Codex CLI binary. Its memory usage is typically pretty tame.

triplewhopper · 6 months ago

Clarifying my earlier post: I’m not using codex exec or automation, but running multiple concurrent interactive Codex CLI sessions on macOS. The workload is CPU-heavy Python analysis spawned by tasks; a VM or remote runner would isolate resources, but it adds overhead and reduces responsiveness for my use. Is there a recommended way to manage concurrency and limit child-process resource usage locally so the machine stays responsive?

etraut-openai contributor · 6 months ago

A VM is one solution, but it's pretty heavy weight. You could try a lighter-weight containment mechanism like a docker container.

I don't think this is something we can solve in the agent harness itself.