Codex Desktop reports completion while a Bun descendant tree survives and respawns for 63 minutes on macOS

Open 💬 1 comment Opened Jul 18, 2026 by dre8597

Summary

Codex Desktop reported a Bun test execution cell as complete after printing only Bun's test header, but the Bun parent remained a direct child of Codex for about 63 minutes and continuously created short-lived descendants.

This process-lifecycle failure immediately preceded a macOS launchd SIGBUS / PID 1 kernel panic and restart. The kernel panic is ultimately an Apple robustness failure; the Codex defect reported here is the execution-completion contract violation: Codex marked the tool call complete without reaping or surfacing the still-live descendant tree.

Environment

Codex Desktop (affected session originator)
Codex runtime recorded in the session: 0.145.0-alpha.18
macOS 27.0, build 26A5378n
Apple Silicon (arm64), MacBookPro18,2
Bun 1.3.14
Affected Codex task: 019f761b-fae3-7c22-b076-15e1e5be7d44
Date: 2026-07-18 (America/New_York)

The exact Desktop UI build was not exposed in the managed session metadata.

Command

PATH=/private/tmp/bun-v1.3.14/bun-darwin-aarch64:$PATH bun test --no-orphans --isolate --parallel=2 apps/core/src/tests/api/terminalPtyAdapter.test.ts apps/core/src/tests/api/terminalService.test.ts apps/core/src/tests/api/inlineImageProcessor.test.ts

Observed behavior

Codex launched the command at approximately 14:06:47 EDT.
The execution cell emitted only the Bun test header and then appeared complete.
The Bun parent remained a direct child of Codex for approximately 63 minutes.
During that interval, macOS unified logs recorded approximately:

78,811 short-lived Bun/Codex process instances
157,617 denied launchd XPC lookups

At approximately 15:10:22 EDT, launchd exited with SIGBUS and macOS panicked/restarted.

The evidence establishes the surviving Codex-owned process tree and the immediate timing. It does not by itself prove that Codex caused the launchd SIGBUS. The diagnostic evidence did not show macOS memory-pressure termination or a container OOM. Docker workload pressure was present, but it does not explain why a supposedly completed Codex execution retained a direct live child and kept creating processes.

Expected behavior

Codex should report an execution complete only after its owned process group has exited or been reaped.

For success, timeout, cancellation, caller disconnect, and internal-error paths, Codex should:

Terminate the owned process group.
Escalate from TERM to KILL after a bounded grace period.
Verify that no owned descendants remain.
Surface an explicit cleanup failure if descendants cannot be reaped.

Reproduction and safety

I do not recommend intentionally reproducing this on a primary workstation because the observed failure ended in a host restart.

A disposable macOS VM or test host could run the command above through the Codex Desktop execution path while monitoring the process tree after the execution cell reports completion. The key assertion is that no Bun process or descendant remains parented to Codex after completion.

Impact

Uncontrolled process churn continued for about 63 minutes with no visible indication that the execution was still active.
The machine froze and restarted.
This behavior can consume host process/XPC capacity even when the UI presents the task as complete.

Local mitigation applied

In the affected project, we switched automatic PTY selection to node-pty, made Bun's terminal backend an explicit canary, added an outer batch timeout with process-group cleanup, serialized heavy execute_code work, and added host-pressure admission controls. These mitigations reduce risk in the project, but they cannot enforce cleanup inside Codex Desktop after Codex has declared its own execution complete.

Evidence available

I can provide sanitized selected session events, process-tree and unified-log extracts, and the macOS panic excerpt privately. I am intentionally not attaching raw rollout data, full system logs, or user-specific filesystem paths to this public issue.