[macOS][Codex App 26.727] Duplicate runaway ffmpeg children consumed ~900% CPU for 7.5 hours

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

Codex App 26.727.40816 (6067); bundled codex-cli 0.146.0-alpha.9.2

What subscription do you have?

ChatGPT subscription (exact tier not provided)

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Summary

Codex App launched two identical, unbounded ffmpeg subprocesses from a task. Both processes remained active for approximately 7.5 hours and together consumed about 8–9 CPU cores continuously. The user noticed the problem only because macOS Activity Monitor showed ChatGPT using nearly all available CPU.

The generated ffmpeg command was intended to render a 1.6-second transition. However, it created an infinite nullsrc inside the filter graph and did not apply a duration limit to the output. The command therefore never terminated naturally.

The command-level mistake is not the main product issue. The Codex App:

• started the same command a second time about 68 seconds later while the first copy was still active;
• allowed both copies to write to the same temporary output path;
• kept both high-CPU subprocesses running for more than seven hours;
• did not provide an obvious warning, timeout, or consolidated stop control for the continued background work.

Observed impact

• Process 1 elapsed time: approximately 7h32m
• Process 2 elapsed time: approximately 7h31m
• CPU per process: approximately 395–462% on macOS
• Combined CPU: approximately 800–920%
• Resident memory per process: approximately 670 MB
• System CPU idle time during inspection: 0–0.5%
• System load average during inspection: approximately 41
• Both processes had the Codex app-server as their direct parent
• Both processes wrote to the same /tmp/theme-peel-native-test.mp4 path

The ChatGPT/Codex UI processes themselves were using relatively little CPU; the sustained load came from their child processes and was attributed to the app by Activity Monitor.

What steps can reproduce the bug?

This is the observed failure sequence. Do not reproduce it without an independent process timeout, because it can saturate the machine indefinitely.

1. In Codex App, ask a task to render a short image transition with ffmpeg.
2. Codex runs a command equivalent to the following, where the input images are duration-limited but the generated nullsrc and final output are not:

ffmpeg -v error -y \
  -loop 1 -framerate 60 -t 1.6 -i image-a.png \
  -loop 1 -framerate 60 -t 1.6 -i image-b.png \
  -filter_complex "[0:v]format=rgba[top];[1:v]format=rgba[bottom];nullsrc=s=1920x1080:r=60,format=gray,geq=lum='if(lte(X+H-Y+35*sin(Y/34)+18*sin(X/23+Y/51),900+N*12),255,0)'[mask];[top][bottom][mask]maskedmerge,format=yuv420p[v]" \
  -map "[v]" -r 60 \
  /tmp/theme-peel-native-test.mp4

1. The infinite filter source keeps producing frames after the two image inputs reach 1.6 seconds.
2. In the observed incident, Codex started the same command again approximately 68 seconds later without stopping the first process.
3. Leave the app open or switch to other tasks.
4. Several hours later, inspect the process tree with ps or Activity Monitor. Both ffmpeg processes remain direct children of the Codex app-server and continue consuming multiple CPU cores each.

The immediate command fix is to apply an output duration such as -t 1.6 immediately before the output path, or cap the frame count. The product issue is that an agent-generated unbounded command and its duplicate were allowed to run indefinitely without lifecycle safeguards or a clear user-facing warning.

What is the expected behavior?

• Every long-running subprocess should remain visibly associated with its originating task and have an explicit stop control.
• Canceling, completing, or abandoning a task should terminate its entire process group unless the user explicitly requested persistent background execution.
• Retrying an identical high-resource command should not silently leave the previous copy running, especially when both write to the same output path.
• The app should warn the user when a task sustains unusually high CPU usage for a long period.
• A bounded timeout or confirmation should be required for commands that continue indefinitely without an explicit background-job request.

Additional information

This appears related to, but is not an exact duplicate of:

• #4337 — shell timeout previously killed only the wrapper rather than the process tree; closed as fixed by #6575.
• #8656 — background tasks continued indefinitely without an in-app kill control; closed as not planned due to insufficient upvotes.
• #35482 — Codex Desktop lost track of a sandboxed child process that consumed disk space. This incident instead involves duplicate direct children of app-server consuming sustained CPU on a newer app version.

The two ffmpeg processes were not reparented to PID 1; they remained direct children of the Codex app-server. This may indicate retained task-execution children rather than classic orphaning.