fix: protect active arg0 helper dirs

[viyatb-oai]

Summary

This keeps live arg0 helper directories from being removed during startup cleanup. Each new helper dir now writes a .pid owner sentinel, and the janitor skips directories whose owner process is still running before falling back to the existing lock-based stale cleanup.

Issues Fixed

• Fixes Unified exec caches stale ~/.codex/tmp/arg0 session path and fails with ENOENT until app restart #16970: prevents Codex Desktop on Windows + WSL2 from caching a now-deleted ~/.codex/tmp/arg0/codex-arg0*/codex-linux-sandbox helper path and failing non-escalated unified exec / apply_patch calls with ENOENT until app restart.
• Expected to address the same stale arg0-wrapper failure mode discussed in apply_patch fails with No such file or directory on existing files in codex-cli 0.118.0 #16791 when it is caused by active helper directories being cleaned up during workspace/session switches. I am not marking apply_patch fails with No such file or directory on existing files in codex-cli 0.118.0 #16791 as closing here because the reports may not be identical.

Root Cause

Codex Desktop sessions can cache helper paths such as ~/.codex/tmp/arg0/codex-arg0*/codex-linux-sandbox. The arg0 janitor previously trusted the helper directory lock as the only signal that another process still owned the directory. On WSL-backed workspaces with CODEX_HOME on the Windows-mounted home, those advisory locks can be unreliable, so a later startup could remove another live session's helper directory. Non-escalated unified exec and apply_patch then fail with ENOENT until the app restarts.

[github-actions]

Closing this pull request because it has had no updates for more than 14 days. If you plan to continue working on it, feel free to reopen or open a new PR.