[Bug] macOS app leaves code_sign_clone directories after quit (~965MB per launch)
已打开 06:34PM - 01 Jun 26 UTC
bug
app
### What version of the Codex App are you using (From “About Codex” dialog)?
Co…dex App 26.527.60818 (ChromiumBaseVersion 148.0.7778.179)
### What subscription do you have?
Unknown / not relevant to this issue
### What platform is your computer?
Darwin 24.6.0 arm64 arm
### What issue are you seeing?
Every time I launch and quit the Codex macOS app, a new directory is left under:
`/private/var/folders/.../X/com.openai.codex.code_sign_clone/code_sign_clone.*`
Each clone is about 965 MB. After launching/quitting Codex multiple times, these directories keep accumulating. On my machine after several app restarts:
```bash
clone dirs: 7
6.5G /private/var/folders/.../X/com.openai.codex.code_sign_clone
```
The directories disappear after reboot because macOS cleans the `/var/folders/.../X` temp area.
This looks related to Chromium's `MacAppCodeSignClone` / `code_sign_clone` mechanism. Clone creation itself may be expected, but inactive clone dirs are not cleaned up after the app quits. I also observed orphaned helper processes after quitting Codex, including multiple `browser_crashpad_handler` processes and `SkyComputerUseService` processes with PPID=1.
### What steps can reproduce the bug?
1. Launch `/Applications/Codex.app`.
2. Quit Codex.app.
3. Check the clone directory:
```bash
find /private/var/folders/*/*/X/com.openai.codex.code_sign_clone -maxdepth 1 -type d -name 'code_sign_clone.*' 2>/dev/null | wc -l
du -sh /private/var/folders/*/*/X/com.openai.codex.code_sign_clone 2>/dev/null
pgrep -fl 'Codex|node_repl|SkyComputerUse|app-server|browser_crashpad_handler'
```
4. Repeat launch/quit several times.
Observed: each launch creates another `code_sign_clone.*` directory, and old inactive clone dirs remain after quitting.
### What is the expected behavior?
After Codex quits, inactive `code_sign_clone.*` directories should be removed by the code-sign-clone cleanup helper. Repeated launch/quit cycles should not keep adding ~965 MB per launch until reboot.
### Additional information
I checked that this does not appear to be caused by my Codex `config.toml`. The issue appears to be in the macOS app / Chromium app lifecycle cleanup.
The active clone may be held by the running Codex process, but old clone directories were not held by open file handles when checked with `lsof +D`. This suggests cleanup is not being triggered or is not completing for inactive clones.
格事格非 06-11 22:162楼