›_ Codex Issues
Codex Issues / #32700

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

Open 💬 8 comments Opened Jul 13, 2026 by Timcai06
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  1. Start Codex Desktop on macOS.
  2. Run tasks that use Computer Use browser automation multiple times.
  3. Inspect the Chrome child process and confirm the Playwright/automation flags.
  4. 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
  1. End the automation sessions without rebooting and observe inactive clones

accumulating.

  1. 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:

  1. Use Chrome for Testing or a bundled managed Chromium runtime for Computer Use.
  2. Reuse one managed browser instance across tool calls.
  3. Always await graceful Playwright/browser shutdown.
  4. Remove inactive owned clone directories during Computer Use startup/exit.
  5. 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 ↗

8 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #32462

Powered by Codex Action

Timcai06 · 1 month ago

This is not a duplicate of #32462.

The two reports involve different platforms, Codex components, leaked resources, and remediation paths:

  • #32462: Windows 11, Codex CLI / codex exec, live orphaned Chrome processes remain after execution and consume CPU.
  • #32700: macOS 26.5.2, Codex Desktop Computer Use, Playwright launches the system-installed Chrome and leaves inactive APFS com.google.Chrome.code_sign_clone bundles on disk across automation sessions. The stale bundles survived process termination and were reclaimed only after reboot.

#32700 also includes direct process ancestry (ChatGPT.app -> codex app-server -> node_repl -> cua_node -> system Chrome), Playwright automation flags, clone version inventory, and before/after disk measurements. The likely fix area is the macOS Computer Use browser runtime/lifecycle (managed browser choice, graceful close, and startup recovery cleanup), rather than the Windows CLI process reaping path.

The automated match appears to be based on the shared terms “Chrome” and “cleanup”. Please keep #32700 open as a separate macOS Computer Use storage-leak report.

eliotgevers · 1 month ago

Confirmed the same core issue on macOS 26.5.1 with Codex Desktop and Chrome 150.0.7871.129. After Computer Use launched the system /Applications/Google Chrome.app through Playwright (automation flags and a playwright_chromiumdev_profile), stale com.google.Chrome.code_sign_clone data accumulated to roughly 14 GB. In our case normal Chrome later stopped launching as well. Stopping the automation/Chrome processes and clearing the stale clone cache restored normal behavior (without a reboot); the Chrome profile was unaffected.

So the trigger and leaked clone location match this report, although our cleanup path and the additional launch failure differed.

Coldain · 1 month ago

Exact macOS Desktop corroboration on a newer build, captured 2026-07-25.

Environment

  • macOS 27.0 (26A5388g), Apple Silicon
  • ChatGPT/Codex Desktop: 26.721.41059
  • bundled runtime: codex-cli 0.146.0-alpha.3.1
  • system Google Chrome: 150.0.7871.187

Local evidence

  • stale directories under /private/var/folders/.../X/com.google.Chrome.code_sign_clone: 78
  • allocated size reported by du: 54.1 GiB
  • clone directory mtimes spanned 2026-07-24 09:16–15:20 local time
  • each clone contained the same Chrome 150 framework; the main framework file was 489,946,480 bytes per clone
  • Computer Use-launched Chrome processes used the system /Applications/Google Chrome.app with --enable-automation, --headless, and scoped temporary user-data directories
  • the clone count and size remained unchanged during diagnosis
  • after active diagnostic processes exited, no stale clone file handles remained open

I have deferred reboot/cleanup so I can first preserve this evidence. The installed version combination and leaked path closely match this issue and extend the reproduction to the current July 21 Desktop build and Chrome 150.0.7871.187.

Coldain · 1 month ago

Follow-up from the same machine after a bounded cleanup:

  • Re-checked the exact clone root: 78 code_sign_clone.* directories, current-user-owned, no unexpected top-level children, and 0 open handles across three checks.
  • Moved only that root to Trash first, then permanently removed only the isolated clone cache. The Chrome app, browser profiles, downloads, and Codex rollout history were not touched.
  • Before removal, du -sk reported 56,702,304 KiB (~54.1 GiB nominal).
  • Immediately after permanent removal, df showed no measurable positive free-space gain (only a small normal fluctuation); the clone root is now absent.

That strongly suggests these are APFS cloned-file/logical-accounting bytes rather than 54 GiB of uniquely allocated blocks. They can still inflate the macOS Storage “System Data” presentation and create filesystem clutter, but the displayed nominal size should not be assumed to equal reclaimable capacity.

A useful fix/diagnostic would report both clone-directory nominal bytes and actually allocated/reclaimable bytes, then perform cleanup automatically when the browser session ends. I’ll also compare the Storage graph again after its next recount/restart.

neonwatty · 9 days ago

I've encountered this issue as well.

Environment:

  • macOS 26.4.1
  • Codex Desktop 26.810.41047
  • Chrome 151.0.7922.138

I found 437 com.google.Chrome.code_sign_clone directories created August 14–17. Many appeared in bursts roughly 11 seconds apart, and 40 were created within five seconds of individual Codex subagent starts. The activity correlated with Codex browser/testing tasks across several projects.

Only two Google Chrome clones and one Chromium clone were still referenced by running processes.

mbenhard · 7 days ago

Confirmed on another machine today (2026-08-20).

Environment:

  • macOS 26.5.2 (25F84), Apple Silicon
  • Codex Desktop 26.818.22352
  • Google Chrome 151.0.7922.138

I found 90 stale directories under /private/var/folders/.../X/com.google.Chrome.code_sign_clone, with mtimes spanning August 3–20. Each clone presented as a complete ~2.1 GiB Chrome app bundle, and du reported approximately 183 GiB nominal total.

The accumulation correlates with repeated Codex browser/Computer Use and QA sessions across multiple projects. Chrome was still holding an active clone when initially inspected, while the older directories had accumulated across prior sessions.

Because these are APFS copy-on-write clones, the 183 GiB du total should not be interpreted as uniquely allocated or fully reclaimable physical space. The clone count and cleanup failure are nevertheless real and match this report. I am performing a bounded cleanup of only this clone root after fully quitting Chrome; the Chrome application and browser profile are not being touched.

dianshili · 6 hours ago

Edge-specific corroboration of #32700

Environment

  • macOS 26.5.2 (25F84), arm64
  • Codex Desktop 26.825.31414 (build 7287)
  • Microsoft Edge 151.0.4129.107
  • Google Chrome 152.0.7977.64

Observed

  • 169 stale directories under

/private/var/folders/.../X/com.microsoft.edgemac.code_sign_clone
with approximately 183 GiB reported by du.

  • 19 directories under

/private/var/folders/.../X/com.google.Chrome.code_sign_clone
with approximately 39 GiB reported by du.

  • Microsoft Edge was no longer running at inspection time.
  • The Edge clone bundles contained 138 copies of version 151.0.4129.93

and 31 copies of version 151.0.4129.101. Both are older than the
currently installed Edge 151.0.4129.107, confirming that the
directories are stale.

  • During one bounded 41-minute interval, Codex-driven browser automation

launched 31 distinct Edge browser processes through repeated close/open
cycles. Exactly 31 Edge code-sign-clone directories were created during
the corresponding interval. This supports a one-clone-per-browser-launch
relationship.

Mechanism

Chromium's CodeSignCloneManager creates a new temporary APFS copy-on-write
clone of the installed application bundle for every browser instance. The
clone preserves code-signature validity if an update is staged while that
instance is running.

During normal shutdown, destruction of CodeSignCloneManager should launch a
code-sign-clone cleanup helper, wait for the browser process to exit, and
delete the instance-specific directory. The stale directories indicate that
this shutdown/cleanup path did not run or did not complete.

Chromium's own source says that only approximately 1–5 in-use clones are
normally expected, that a high count indicates a more robust cleanup approach
is needed, and contains a TODO to search for and remove inactive clones when
the count becomes high:

The du totals above are nominal filesystem-accounting figures. Because these
are APFS copy-on-write clones, they should not be interpreted as an equal
amount of uniquely allocated or fully reclaimable physical storage.

This extends the issue from system Google Chrome to system Microsoft Edge and
suggests that the common trigger is repeated creation and teardown of installed
Chromium-browser processes by Codex automation.

Requested product-side mitigations

  1. Reuse a managed browser instance instead of repeatedly closing and

relaunching the system browser.

  1. Await graceful browser shutdown and verify completion of clone cleanup.
  2. Prefer Chrome for Testing or another managed runtime where this

auto-update-specific clone feature is disabled.

  1. On startup and shutdown, detect and safely remove inactive clone

directories owned by prior Codex browser sessions.

  1. Warn or record diagnostics when the stale-clone count becomes abnormal.