[macOS][Codex Desktop] Simulator workflows can exhaust RAM and disk, destabilizing the whole system

What version of the Codex App are you using?

Latest Codex Desktop version available as of 2026-07-21.

What subscription do you have?

ChatGPT Pro (20x usage tier).

What platform is your computer?

• MacBook Pro (Mac15,3), Apple M3
• 16 GB RAM
• macOS 26.5.2 (25F84)
• Xcode 26.6 (17F113)

What issue are you seeing?

During repeated iOS build, test, and debugging work, Codex Desktop can boot or use multiple iOS Simulators and create simulator/Xcode artifacts without returning the machine to a safe resource baseline afterward.

Over longer sessions, simulator processes/state and build artifacts consume increasing RAM and disk space. Memory pressure and swap rise, and the disk can become full or nearly full. The resulting system-wide resource exhaustion makes unrelated applications slow, unresponsive, or unusable.

Chrome was one visible casualty in my case: it became unusable and websites were logged out afterward. However, this is not a Chrome-specific report. Any application that needs memory or must persist data may be affected when Codex-driven workflows exhaust RAM and free disk space. Macs with limited RAM or limited remaining storage are likely especially vulnerable.

I am also not claiming that Codex directly modifies or corrupts Chrome data. The logout behavior may be a downstream effect of memory pressure, forced application termination, or failure to write cookie/profile databases while the disk is full.

The issue is intermittent and appears after sustained or repeated simulator-heavy Codex work rather than one deterministic command.

What steps can reproduce the bug?

1. Open an iOS project in Codex Desktop on a Mac with limited RAM or free disk space.
2. Ask Codex to iteratively build, run, test, and debug the app using iOS Simulator.
3. Allow multiple cycles, retries, cancellations, or concurrent task activity without manually shutting down simulators or cleaning build artifacts.
4. Monitor Activity Monitor, swap usage, free disk space, ~/Library/Developer/CoreSimulator, and Xcode DerivedData.
5. Observe multiple simulator-related resources and build artifacts accumulating while memory pressure and disk usage rise.
6. Continue the workflow until the system is under severe memory pressure or disk space becomes critically low.
7. Observe unrelated applications becoming slow, unresponsive, terminated, or unable to persist state.

What is the expected behavior?

Codex should manage and bound the lifecycle of resources it starts or creates during simulator-heavy workflows:

• Reuse an already booted simulator where appropriate.
• Default to one simulator/build at a time on resource-constrained machines unless parallelism is required or approved.
• Shut down simulators and helper processes that Codex started when the task completes, fails, or is cancelled.
• Clean up or apply a documented retention limit to Codex-owned DerivedData, .xcresult bundles, temporary build directories, logs, and other generated artifacts.
• Preserve unrelated user-owned simulator data and Xcode artifacts.
• Check available RAM, memory pressure, swap, and free disk space before and during long-running workflows.
• Warn and pause before the machine reaches critical memory or disk pressure.
• Verify that Codex-owned resource usage returns to a bounded baseline before reporting the task complete.
• Provide user-configurable limits for simulator/build concurrency and minimum free disk space.

What actually happens?

There is no clear resource-budget warning or end-of-task cleanup summary. Simulator-heavy work can continue until the entire machine is severely memory constrained and storage is exhausted. This affects unrelated applications and risks failed or interrupted writes across the system.

Current measurements

These were collected after the peak incident, not at the exact moment the disk filled:

• ~/Library/Developer/CoreSimulator: approximately 34 GB
• ~/Library/Developer/Xcode/DerivedData: approximately 3.8 GB
• Current free disk space after the incident: approximately 117 GiB
• Exact free-space low-water mark and peak swap usage during the incident were not captured.

Impact

• The entire Mac becomes slow or temporarily unusable.
• Unrelated applications can hang, crash, or be terminated.
• Applications may fail to save databases, preferences, cookies, or session state.
• Browser sessions may be lost and require sign-in again.
• Manual simulator shutdown, storage cleanup, and sometimes a reboot may be required.
• Systems with lower RAM or less free storage are likely affected sooner.

Related issue

This appears related to #33707, which reports unbounded Xcode/simulator resources created by Codex-generated test infrastructure. This report adds an independent Codex Desktop reproduction and emphasizes the broader system-wide impact on resource-constrained computers.

A useful regression test would repeatedly run a simulator-heavy iOS workflow on a constrained machine and assert that task-owned processes and disk artifacts either return to baseline or remain within documented limits after success, failure, and cancellation.

I can provide additional redacted diagnostics or capture before/after process, memory, swap, simulator, and disk measurements during the next occurrence if needed.