Process lifecycle hardening: track and clean up descendants of nested commands on macOS

Summary

Request explicit process ownership and cleanup guarantees for nested commands on macOS. Descendants can remain active after a nested wrapper exits, causing sustained background resource usage.

Scope: this observation involves a custom nested command runner used from a Codex workflow. It is not a standalone reproduction of a defect in Codex itself; the confirmed cleanup gap is in the nested runner. Please treat this as a containment/test-coverage consideration for Codex, not proof of a Codex-specific root cause.

Observed locally:

• Several recursive search processes remained alive after their associated nested sessions had ended. Three sessions exited successfully; another stopped at an application-level limit.
• The surviving processes had PPID 1 and separate process-group IDs. One persisted for more than an hour.
• The searches traversed from the filesystem root. Sustained disk activity and elevated endpoint-scanner CPU were observed concurrently; their exact causal contribution was not isolated.
• No original search terms, paths, process IDs, session identifiers, screenshots, or diagnostic dumps are included here.

The nested runner's cleanup pattern was effectively:

process = subprocess.Popen(command, start_new_session=True, ...)
try:
    process.communicate(timeout=limit)
except subprocess.TimeoutExpired:
    os.killpg(process.pid, signal.SIGKILL)
    process.communicate()
finally:
    close_service_connections()

There was no descendant cleanup on successful exit or application-level early exit. Killing only the original process group would also not cover descendants that create a different group/session. Permission to send termination signals alone does not establish complete cleanup.

Suggested regression coverage (not yet executed against standalone Codex):

1. Use an inert, short-lived sleep process in a disposable directory, rather than a filesystem scan.
2. Launch it through a nested wrapper, including a variant that creates a separate process group/session.
3. Exercise normal wrapper exit, nonzero exit, cancellation, and timeout separately.
4. Verify that all processes owned by the command have exited, or are explicitly tracked as intentionally persistent background work.
5. Ensure cleanup does not target unrelated user processes and that a successful wrapper exit is not mistaken for confirmed descendant cleanup.

It would be useful to clarify the outer command runner's ownership/containment guarantees for this case and expose any surviving owned processes when cleanup is incomplete.

Related issue

Related to https://github.com/openai/codex/issues/15379. This standalone report focuses on nested wrappers, separate process groups, and cleanup after successful or application-limited exits. The same sanitized observations were previously added there as a comment.

Start by locating Codex's outer command runner and its existing process cleanup and ownership handling; no specific source file or test is named in the report. Add regression coverage using inert sleep processes through nested wrappers, including separate process groups, and cover normal exit, nonzero exit, cancellation, and timeout. Done means owned descendants are cleaned up or explicitly tracked, without affecting unrelated processes.