-
Notifications
You must be signed in to change notification settings - Fork 10.2k
Feature request: Global memory budget and proactive OOM protection for Codex CLI #11523
Copy link
Copy link
Closed as not planned
Closed as not planned
Copy link
Labels
CLIIssues related to the Codex CLIIssues related to the Codex CLIenhancementNew feature or requestNew feature or requestsandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing
Description
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?
- 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
- Proactive behavior before host instability:
- soft-threshold warnings
- hard-threshold action (pause/deny new tasks, then terminate child tree gracefully with force-kill fallback)
- 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
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
CLIIssues related to the Codex CLIIssues related to the Codex CLIenhancementNew feature or requestNew feature or requestsandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing