Codex generated broken concurrency control that launched 80+ ML processes and caused repeated macOS kernel panics

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

26.803.41515

What subscription do you have?

pro

What platform is your computer?

mac

What issue are you seeing?

Codex generated and executed a shell script with ineffective concurrency control while transcribing audio with mlx_whisper. Instead of limiting the workload to 6–8 concurrent processes, the script launched almost every job at once.

This exhausted unified memory and the macOS memory compressor, froze the machine for 94 seconds, and caused a watchdog kernel panic and forced reboot.

The same failure occurred twice on the same machine.

Environment

• Product: Codex desktop app for macOS
• App version: 26.803.41515
• App build: 6321
• Model: gpt-5.6-sol
• Reasoning effort: high
• macOS: 26.5.1 (25F80)
• Hardware: Mac Studio, Apple M4 Max, 16 CPU cores, 64 GB unified memory
• Shell used by Codex: zsh

What Codex was doing

I asked Codex to transcribe several approximately three-minute audio files.

Codex split the audio into short chunks and attempted to process those chunks concurrently with mlx_whisper. It generated concurrency control similar to:

while [ "$(jobs -pr | wc -l | tr -d ' ')" -ge 6 ]; do
sleep 0.2
done

and, in the earlier incident:

while (( $(jobs -rp | wc -l) >= 8 )); do
wait -n
done

In this zsh execution environment, jobs inside command substitution did not see the parent shell's background job table. The expression therefore returned zero and the concurrency limit never activated.

Actual result

Incident 1, August 4, 2026:

• 56 concurrent python3.11/mlx_whisper processes
• Approximately 112 GiB aggregate RSS
• Memory compressor segment limit: 100% (BAD)
• 71 swap files
• Kernel panic: watchdogd failed to check in for 94 seconds
• Forced reboot

Incident 2, August 8, 2026:

• 86 concurrent python3.11/mlx_whisper processes
• Approximately 120 GiB aggregate RSS
• Memory compressor segment limit: 100% (BAD)
• 66 swap files
• Kernel panic: watchdogd failed to check in for 94 seconds
• Forced reboot

The reset reports contain:

Boot faults: wdog,reset_in_1

The panic reports contain:

watchdog timeout: no checkins from watchdogd in 94 seconds

The runaway Python processes were all part of the Codex process coalition. There was no evidence of thermal shutdown, power loss, or a third-party kernel extension failure.

Safe minimal reproduction of the concurrency bug

This demonstrates the broken limiter without running any ML workload:

zsh -lc '
for i in {1..10}; do
sleep 3 &
while [ "$(jobs -pr | wc -l | tr -d " ")" -ge 3 ]; do
sleep 0.05
done
done
jobs -pr
wait
'

Expected: no more than three background jobs.

Actual: all ten background jobs are launched.

Expected Codex behavior

1. Codex should generate concurrency control that works in the selected shell.
2. Resource-intensive local ML workloads should default to conservative concurrency.
3. Codex should detect rapidly growing process count or memory pressure and pause or terminate the spawned process tree before the host becomes unresponsive.
4. When a command can create dozens of model processes, Codex should estimate the resource impact or ask for confirmation.
5. Cancelling or losing the Codex task should terminate its entire subprocess tree.

Impact

Severity is high because this did not merely crash a command or the Codex app. It caused two complete operating-system freezes and forced kernel-level reboots, with a risk of data loss.

Suggested fix

• Avoid using jobs inside command substitution for concurrency tracking.
• Use a reliable worker pool, semaphore, explicit PID array, or a tool such as xargs -P.
• Apply a conservative default concurrency limit for GPU/unified-memory ML inference.
• Add process-tree and memory-pressure safeguards in the Codex execution layer.

What steps can reproduce the bug?

1. On macOS, ask Codex to transcribe multiple audio files using mlx_whisper.
2. Have Codex split the audio into many short chunks and process them concurrently.
3. Codex generates and executes concurrency control like:

while [ "$(jobs -pr | wc -l | tr -d ' ')" -ge 6 ]; do
sleep 0.2
done

1. In Codex's zsh environment, jobs inside command substitution does not see the parent shell's background jobs, so the expression incorrectly returns zero.
2. The concurrency limit is never enforced, causing dozens of mlx_whisper/Python processes to launch simultaneously.
3. Memory and swap are exhausted, the system becomes unresponsive, and macOS eventually restarts due to a watchdog kernel panic.

A safe reproduction without ML workloads is:

zsh -lc '
for i in {1..10}; do
sleep 3 &
while [ "$(jobs -pr | wc -l | tr -d " ")" -ge 3 ]; do
sleep 0.05
done
done
jobs -pr
wait
'

All ten jobs launch even though the intended limit is three.

What is the expected behavior?

Codex should enforce the requested concurrency limit and launch no more than the configured number of background processes.

For resource-intensive workloads such as local ML inference, Codex should use a reliable worker pool or semaphore, default to conservative concurrency, and stop or pause the process tree if process count or memory pressure grows unexpectedly.

A generated command should not be able to exhaust host memory, freeze macOS, or cause a kernel-level reboot.

Additional information

_No response_