Codex Desktop sandboxed exec loses a running child process, allowing a deleted log to consume 205 GB

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

26.721.41059 (5848); bundled codex-cli 0.146.0-alpha.3.1

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Summary

Codex Desktop lost track of a still-running sandboxed child process. The child entered a high-speed interactive error loop and wrote to a redirected log under /tmp. The agent then deleted the visible log without terminating the child. Because the process still held the deleted file descriptor open, APFS continued allocating space invisibly until the disk was effectively full.

This was not a 205 GB archive. The input was a corrupted Playwright trace ZIP of only 63,546 bytes. The missing space was an unbounded error log held open after deletion.

Impact

• Available disk space fell from more than 200 GB to about 100 MB.
• Other Codex sessions began failing with disk-full / unable-to-write errors.
• Codex Desktop did not surface a low-disk warning or show that the child process was still running.
• Finder and du could not locate the missing space after the log was deleted.
• When the child finally exited, approximately 205.6 GB was released immediately.
• This creates risk of application/database corruption and unnecessary SSD writes.

Observed process tree

launchd -> ChatGPT -> codex -> zsh -> zip

The runaway process was observed as PID 47113.

Exact failure sequence

1. A corrupted Playwright trace.zip could not be read normally.
2. Codex ran zip -FF against a copy in /tmp and redirected stdout/stderr to /tmp/080d-zipfix.log.
3. The exec tool returned after 10.2 seconds as if the script had completed, with no visible output, but the zsh -> zip process continued running.
4. zip -FF repeatedly prompted for a missing split file, 080d-trace-broken.z01, at very high speed.
5. Within roughly 16 seconds, the log had already reached 2,067,307,609 bytes (reported by du as 2.4 GB), while the input ZIP remained 63,546 bytes.
6. Codex attempted pgrep -fl 'zip -FF', but the sandbox returned sysmon request failed with error: sysmond service not found and pgrep: Cannot get process list.
7. Despite being unable to verify termination, Codex ran rm -f on the log and temporary ZIP files.
8. The active zip process kept writing to the now-deleted log inode. The allocation became invisible to normal file searches but remained visible in df/APFS usage.
9. The process continued for about 45 minutes and consumed roughly 205.6 GB before exiting.

Session

• Thread ID: 019f9c7d-dcd3-7911-b3f5-122a737c32ec
• Originator: Codex Desktop
• History mode: legacy
• Workspace paths and application code details have been redacted.

What steps can reproduce the bug?

This is the observed reproduction. Please use a strict file-size limit if attempting to reproduce; the original behavior can exhaust the disk.

1. In Codex Desktop with the workspace-write sandbox, run a shell-wrapped command that invokes zip -FF on a malformed/truncated ZIP that is interpreted as a missing split archive.
2. Redirect its output to a writable temp file:

zip -FF /tmp/broken.zip --out /tmp/fixed.zip >/tmp/zipfix.log 2>&1

1. Let the exec call yield after approximately 10 seconds.
2. Observe whether Codex retains and surfaces the running terminal/session ID. In this incident, the outer tool result said the script completed while the child remained active.
3. From inside the macOS sandbox, try to inspect the child with pgrep; it may fail with sysmond service not found.
4. If the output path is unlinked while the child is still writing, du no longer shows the space, but df continues falling until the child exits.

The repeating output was the interactive prompt for the missing .z01 split file. A safe reproduction should cap output/file size and terminate the entire process group after a few seconds.

What is the expected behavior?

• A yielded or timed-out exec command must remain visible as a running background terminal with a retained session/kill handle.
• If the session handle is dropped or the turn is aborted, Codex should terminate the entire process group, not only the shell wrapper.
• The sandbox should allow Codex to inspect and terminate child processes that Codex itself created.
• Interactive commands running without usable stdin should time out or fail instead of spinning indefinitely on EOF.
• Codex should warn and pause when a task is consuming disk rapidly or free space crosses a critical threshold.
• Temp/task storage should have a quota or another backpressure mechanism so one runaway command cannot exhaust the host disk.
• The UI should clearly warn when a process keeps an unlinked file open and disk space is not reclaimed.

Additional information

Environment and measurements

• Codex App: 26.721.41059 (5848)
• Bundled Codex CLI: 0.146.0-alpha.3.1
• macOS: Darwin 25.5.0 arm64
• Sandbox: workspace-write
• Input archive: 63,546 bytes
• Runaway log after about 16 seconds: 2,067,307,609 bytes / 2.4 GB allocated
• APFS container free space during incident: about 95.8 GB and falling
• APFS container free space after child exit: about 301.4 GB
• Immediate recovery: about 205.6 GB
• Final available space after recovery: about 281 GiB

Related issues

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

• #26869 — Codex Desktop app-server loses child processes and writes excessive logs after crash/restart. It overlaps in process-lifecycle symptoms, but this report has a deterministic single-command trigger and a 205.6 GB deleted-open temp log.
• #8656 — background tasks keep spinning and macOS sandbox blocks pgrep
• #4337 — shell wrapper timeout does not terminate child processes
• #7852 — sandboxed exec leaves orphaned child processes
• #4775 — default timeout and feedback for shell commands
• #22444 — deleted files remain allocated because Codex processes hold descriptors open
• #16886 — unbounded Codex logs filling disks
• #34061 — Codex session data exhausting APFS volumes without quotas or warnings

I have retained the local session evidence and can provide a redacted diagnostic excerpt or submit it through /feedback if requested. I have not attached the full session because it contains private prompts, local paths, and tool output.