Aident AI

Codex App Fork Failed on Mac? Clear Zombie Processes
If the Codex app on macOS starts returning fork failed: resource temporarily unavailable and a read-only process check shows a growing set of Z or <defunct> children, save your work and fully quit Codex with Command-Q. Wait for the parent app to exit, verify that the zombie count falls, then reopen Codex with one short task. If the app will not quit normally, use Apple's Force Quit window. Do not kill zombie PIDs one by one, raise macOS process limits, run a cleanup command with sudo, or delete Codex state.
Three public reports opened on August 6, 2026 describe this same boundary: the Codex app accumulates zombie child processes, macOS eventually refuses another fork, and a full app quit clears the process-table entries. One report counted about 2,373 zombies, another about 4,875, and a smaller reproduction reached 77 within two minutes. These reports establish a recurring symptom and a containment step. They do not establish an official OpenAI root cause or a permanent client-side fix.
Confirm the Exact Failure Shape
This guide owns the combination of a macOS fork error and processes whose status begins with Z. Other resource failures need a different diagnostic.
What you observe | Likely boundary | Next step |
|---|---|---|
| Unreaped child-process buildup | Preserve work, fully quit the parent app, and verify cleanup |
One Codex process consumes large RAM or swap, but zombie count stays near baseline | Memory growth rather than process-table exhaustion | Use the Codex high-memory guide |
A command remains active and still has CPU or I/O activity | Live child process, not a zombie | Stop it through its owning task or program |
Only one task is stuck on | Workspace dependency or terminal boundary | Use the stuck command diagnostic |
Weekly usage falls rapidly while processes look normal | Metering or retry-loop issue | Use the Codex usage-spike diagnostic |
A zombie has already exited. Its parent has not yet collected the child's final status, so the entry remains in the process table. Sending another signal to the zombie cannot make it exit a second time. The useful question is which parent owns the entries and whether restarting that parent makes the count return to baseline.
Capture a Read-Only Snapshot
Stop starting new Codex work, save open editor files, and check the repository before restarting the app:
Then list zombie processes without changing anything:
Count them separately so you can compare before and after the restart:
Expected result: the first column begins with Z, and repeated rows share one or a small number of parent PIDs. Record the count, repeated parent PID, Codex version, macOS version, and the last task type. Do not upload the full command column without checking it for local paths, repository names, tokens, or other private data.
To inspect one repeated parent PID, replace 12345 with the numeric PPID from the snapshot:
If the parent is not part of Codex or ChatGPT, stop here. Quitting Codex will not repair an unrelated process tree.
Quit the Parent App, Not Each Zombie
Use the smallest recovery that matches the evidence:
Stop active Codex tasks and save work in Codex, your editor, and your repository.
Choose Codex > Quit Codex or press Command-Q. Closing the last window is not the same as quitting the app.
Wait for the app to disappear from the menu bar and Dock activity to settle.
Run the zombie count again.
If Codex is unresponsive, press Option-Command-Esc, select Codex, and choose Force Quit. Apple warns that unsaved changes may be lost.
If the parent still cannot exit, restart macOS through the Apple menu after preserving work.
Expected result: the repeated zombie entries disappear or return close to the pre-Codex baseline, and macOS can create processes again. This is containment. It does not prove that the underlying Codex lifecycle bug is fixed.
Avoid shell-wide cleanup commands such as killall, pkill -f, or a loop that kills every process matching codex, node, or bash. A Codex task can legitimately own terminals, development servers, test runners, or other work you do not want to terminate. Do not raise kern.maxproc, change launch limits, or disable macOS protections to make room for a leaking parent.
Verify That the Buildup Does Not Resume
After reopening Codex, do not immediately restore every long-running task and integration. Run a bounded negative control:
Record the zombie count before opening a new task.
Start one short, read-only task with no subagents or background commands.
Let the task finish, then wait five minutes.
Record the count again.
Add one previously active dimension, such as an MCP server, browser task, subagent, or background command, and repeat.
Expected result: the count stays near baseline after the task finishes. If it rises after one dimension returns, you have a useful reproduction boundary. Stop repeating the trigger before process creation fails again.
OpenAI's current Codex app troubleshooting guide recommends restarting the app after active tasks finish when stuck behavior persists. The August issue reports make the extra zombie-count check useful for this exact symptom, but the restart advice remains a workaround until an upstream change is verified.
Report a Small, Sanitized Reproduction
Add evidence to the closest existing issue instead of opening another duplicate. Include:
Codex app and macOS versions;
the exact
fork failedtext;zombie count before the task, after the task, and after quitting Codex;
the repeated parent process name and PID, without unrelated command lines;
whether the trigger used MCP, Computer Use, a subagent, or a background command;
whether one fresh read-only task stayed stable;
how long the buildup took.
Do not attach raw session files, full process listings, crash archives, screenshots, or command output until you have removed secrets, private prompts, local paths, and repository names.
Retest after a Codex update. Remove the restart containment only when the same bounded workload completes repeatedly, its child processes are reaped, and the zombie count stays near baseline while idle.
Track the Upstream Fix Without Editing Issues
You can use Aident Loadout to check whether the reports were closed, linked to a release, or given a verified workaround without pasting a GitHub token into the agent. Give Codex the canonical setup instruction:
Follow https://aident.ai/SETUP.md
Then use this bounded prompt:
Check my Aident Loadout account and Vault status. Find a connected read-only GitHub issue search Action, inspect its current schema, and preflight it. Return up to five open
openai/codexissues that mentionfork failed,resource temporarily unavailable,zombie, orunreaped. Include issue number, title, status, and updated time. Do not create or edit issues, post comments, change files, or ask for a provider key.
Success is measurable: you receive at most five current issue records, the Action performs zero GitHub writes, and no credential appears in the prompt or result. Ready to monitor the fix safely? Set up Aident Loadout and run the read-only issue check.
Sources
OpenAI Codex issue #37249: macOS zombie buildup causes fork failures
OpenAI Codex issue #37247: thousands of zombie children accumulate
OpenAI Codex issue #37244: zombie count grows during a short reproduction
OpenAI Codex issue #25744: earlier macOS helper and zombie accumulation report
OpenAI Codex issue #12491: earlier unreaped MCP child-process report
Refresh this guide when the cited issues change state, OpenAI documents the affected child-process lifecycle, a Codex release verifies a fix, macOS changes its process controls, or the linked Aident setup and diagnostic guides change.



The one tool
for every tool
your agent needs.
Give any AI agent real capabilities in seconds. Connect 1,000+ tools once, skip the setup headache, and let your agents execute.
