[macOS][Computer Use] launches system Chrome and leaves code_sign_clone bundles until reboot

Open 💬 3 comments Opened Jul 13, 2026 by Timcai06

Summary

Codex Computer Use launches the system-installed Google Chrome through
Playwright. Repeated automation sessions leave stale
com.google.Chrome.code_sign_clone bundles under /private/var/folders/.../X/.

This is distinct from the already reported com.openai.codex.code_sign_clone
leak: Computer Use also causes the user's system Chrome application to be
cloned repeatedly, and those clones remained until macOS was rebooted.

Environment

macOS 26.5.2 (25F84), arm64
Codex desktop version 26.707.61608
App bundle path: /Applications/ChatGPT.app
Bundle identifier: com.openai.codex
Google Chrome 150.0.7871.114

Process evidence

The observed process ancestry was:

ChatGPT.app
-> codex app-server
-> node_repl
-> cua_node
-> Google Chrome

The child Chrome process was launched from the system application and included:

/Applications/Google Chrome.app/Contents/MacOS/Google Chrome
--enable-automation
--headless
--remote-debugging-pipe
--user-data-dir=/var/folders/.../T/playwright_chromiumdev_profile-...

This ties the automated Chrome process directly to the Codex Computer Use
runtime rather than to a user-started Playwright or ChromeDriver process.

Observed impact

Before reboot:

33 com.google.Chrome.code_sign_clone directories
approximately 65.85 GB reported by du
8 stale com.openai.codex.code_sign_clone directories
approximately 10.08 GB reported by du
Chrome clone versions present: 149.0.7827.104, 149.0.7827.201, and

150.0.7871.114

Codex clone versions were all older than the installed app version

The bundles are APFS copy-on-write clones, so du may overcount shared extents.
However, after an unrelated cache cleanup had completed, rebooting and allowing
macOS to remove the stale clones increased free space reported by df by
approximately 40 GiB.

After reboot:

Chrome clones: 1, held open by the currently running normal Chrome process
Codex clones: 0
the remaining Chrome process had no automation, headless, or Playwright flags

Steps to reproduce / inspect

Start Codex Desktop on macOS.
Run tasks that use Computer Use browser automation multiple times.
Inspect the Chrome child process and confirm the Playwright/automation flags.
Count and measure both clone roots:

find /private/var/folders/*/*/X/com.google.Chrome.code_sign_clone \
  -mindepth 1 -maxdepth 1 -type d 2>/dev/null | wc -l
du -sh /private/var/folders/*/*/X/com.google.Chrome.code_sign_clone 2>/dev/null

find /private/var/folders/*/*/X/com.openai.codex.code_sign_clone \
  -mindepth 1 -maxdepth 1 -type d 2>/dev/null | wc -l
du -sh /private/var/folders/*/*/X/com.openai.codex.code_sign_clone 2>/dev/null

End the automation sessions without rebooting and observe inactive clones

accumulating.

Reboot macOS and observe that the stale clones are removed.

Expected behavior

Computer Use should not leave inactive clones of the user's system Chrome after
an automation session ends. The user should not need to reboot macOS to reclaim
the storage.

Potential fixes:

Use Chrome for Testing or a bundled managed Chromium runtime for Computer Use.
Reuse one managed browser instance across tool calls.
Always await graceful Playwright/browser shutdown.
Remove inactive owned clone directories during Computer Use startup/exit.
Add crash-recovery cleanup and abnormal clone-count telemetry.

Chromium disables this code-sign-clone feature for Chrome for Testing, and its
tracker has previously recorded a ChromeDriver clone-cleanup defect.

Related issues

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗