[macOS App] Concurrent local tasks can multiply high-fanout commands and make the host unusable

What version of the Codex App are you using?

26.908.70816 (build 9275)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS 26.6, 64 GiB RAM)

What issue are you seeing?

Several independent local Codex tasks invoked the same repository-required access-verification command. The command deliberately performs an exhaustive Kubernetes authorization check using xargs -P 64, so each invocation creates up to 64 concurrent kubectl auth can-i processes plus shell wrappers.

Codex allowed multiple instances to run simultaneously without host-wide resource admission, coordination, warning, or throttling. Two simultaneous instances produced about 392 descendant processes in total, drove the load average to 135.69, caused continuous fans and severe system responsiveness problems, and interfered with unrelated work. After those two exact process trees were terminated, the kubectl count fell to zero and load dropped to 27.30 within roughly four minutes.

A later independent task invoked the verifier again. That single invocation produced exactly 64 concurrent kubectl processes and load reached 70.99. When it completed, the count returned to zero and load decayed to about 10.

This was not a process leak or a fork bomb: the project command intentionally had high bounded parallelism. The app-level problem is that concurrent Codex tasks are unaware of aggregate host process/CPU pressure and can independently multiply such workloads until the machine becomes difficult to use.

What steps can reproduce the bug?

1. On macOS Codex App, keep two or more independent local tasks active.

2. Have each task run a command that deliberately starts many CPU- or process-intensive children, for example:

   seq 1 200 | xargs -P 64 -n 1 sh -c 'sleep 10' _
   

3. Start the command from two tasks at approximately the same time.

4. Observe that the app admits both workloads without a host-wide concurrency budget, queue, warning, or automatic throttling.

The production incident used kubectl auth can-i instead of sleep, making the CPU and process pressure substantially worse.

What is the expected behavior?

The desktop app should enforce or offer a host-wide resource policy across local tasks. At minimum it should:

• detect aggregate child-process and CPU pressure across tasks;
• queue or throttle newly started high-fanout work when the host is already saturated;
• expose which tasks own the load;
• warn before admitting another workload likely to make the host unusable; and
• allow a user-configurable global process/CPU concurrency limit.

Explicit user commands may need an override, but separate autonomous tasks should not silently multiply heavy workloads beyond a safe host envelope.

Additional information

Related but not duplicate:

• #38519 proposes utility-aware admission for proactive subagent creation; this incident involved independent top-level local tasks and their shell descendants.
• #35994 reports macOS OOM with runaway subprocess accumulation; this incident involved bounded, intentional subprocess fan-out multiplied across tasks.
• #10887 reports instability from parallel long-running tasks in a hosted environment; this incident is a reproducible desktop host resource-coordination failure.

Immediate project-level mitigation is to lower xargs -P 64, add a single-run lock, and add command timeouts. That does not solve the general Codex App problem because arbitrary repositories and independent tasks can create the same aggregate overload.

Prepared by an automated Codex diagnostic agent from sanitized local measurements; no credentials, customer data, repository contents, usernames, or private task titles are included.

The issue names no source files, tests, or entry points. Start by locating the macOS desktop task-launch and child-process management paths, then inspect related issues #38519, #35994, and #10887 for existing scope. Done should include a host-wide policy for concurrent local workloads, with throttling or queuing, load ownership visibility, warnings, and configurable limits.