[Bug] macOS app leaves code_sign_clone directories after quit (~965MB per launch)

What version of the Codex App are you using (From “About Codex” dialog)?

Codex 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:

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?

Launch /Applications/Codex.app.
Quit Codex.app.
Check the clone directory:

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'

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.

Additional sanitized confirmation from another macOS machine:

Codex App version: 26.602.40724
macOS: 15.7.x
Clone path pattern: /private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone/code_sign_clone.<suffix>/Codex.app.bundle
Observed clone dirs: 7
Total disk usage: about 6.5G
Per-clone size: about 943M-962M, roughly matching the installed Codex.app bundle size
Stale clones spanned multiple Codex app builds (26.527.*, 26.601.*, 26.602.*) and Chromium framework versions (148.0.7778.179, 149.0.7827.54)
No open file handles under com.openai.codex.code_sign_clone were found with lsof at the time of inspection

This supports the existing diagnosis that inactive macOS Chromium code-sign clone directories are accumulating across launches/updates and are only reclaimed when macOS clears /var/folders/.../X on reboot. The impact can be material on low-free-space machines: in this case the stale Codex clone directory was several GB and large enough to contribute to unrelated Docker failures from low disk headroom.

No machine-specific temp token, username, workspace path, process ID, or session identifier is included here.

Additional confirmation from another macOS machine:

Codex App version: 26.609.41114
macOS: 15.7

Clone path pattern:

/private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone/code_sign_clone.<suffix>/Codex.app.bundle

In my case, the stale clone directory grew to about 16GB:

16G  /private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone

The output of du shows multiple code_sign_clone.* directories, each containing a copied Codex.app.bundle:

1.2G  /private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone/code_sign_clone.PBV8Cy/Codex.app.bundle
1.2G  /private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone/code_sign_clone.lqSuRC/Codex.app.bundle
1.2G  /private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone/code_sign_clone.cNVyK3/Codex.app.bundle
1.2G  /private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone/code_sign_clone.5euQzW/Codex.app.bundle
1.0G  /private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone/code_sign_clone.s8pZXb/Codex.app.bundle

/private/var/folders was taking about 17GB, and almost all of it came from com.openai.codex.code_sign_clone.

I also checked with lsof, and no open file handles were found under com.openai.codex.code_sign_clone at the time of inspection.

This seems to support the existing diagnosis that inactive macOS code-sign clone directories are accumulating across launches/updates and are not being cleaned up promptly.

The impact can be significant on low-free-space machines, since the stale Codex clone directory alone took about 16GB in my case.

No machine-specific temp token, username, workspace path, process ID, or session identifier is included here.

my file has grown up to 125GB!!!

Additional confirmation from another macOS machine, this time with a much larger accumulation on a current Codex build.

Codex App version: 26.616.32156
macOS: 26.6 (25G5028f)
Darwin: 25.6.0 arm64

Observed path pattern:

/private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone/code_sign_clone.<suffix>/Codex.app.bundle

Disk usage before manual cleanup:

130G  /private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone
104   code_sign_clone.* directories

App Cleaner also attributed the Codex app removal set to roughly 153G / 42.5K items. The bulk was not ~/Library/Application Support/Codex, ~/.codex, or the app bundle itself; it was the X/com.openai.codex.code_sign_clone tree.

A size-ranked scan showed the stale clone tree dominating all Codex/OpenAI-named paths:

136047988 KB  /private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone
  9971296 KB  /Users/<redacted>/RustProjects/codex-src
  7818480 KB  /Users/<redacted>/.codex
  2167116 KB  /Users/<redacted>/RustProjects/unified-codex-provider
  1434424 KB  /Users/<redacted>/.cache/codex-runtimes
  1390012 KB  /Applications/Codex.app

lsof +D showed only one currently active clone held by the running Codex process:

Codex <pid> txt REG ... /private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone/code_sign_clone.19JFpq/Codex.app.bundle/Contents/MacOS/Codex

I then removed the inactive clone directories while keeping the one active clone. After cleanup:

1.3G  /private/var/folders/<redacted>/<redacted>/X/com.openai.codex.code_sign_clone
1     code_sign_clone.* directory

So in this case, 103 stale clones accounted for roughly 128G of reclaimable space. The current running process needed only one clone. This strongly suggests the cleanup path for inactive macOS code-sign clones is still not running reliably after Codex launches/updates/quits.

This is especially painful because GUI uninstall/cleaner tools surface it as Codex taking 150GB+, and using those tools risks deleting unrelated Codex data/projects unless the user manually inspects the paths.

No machine-specific temp token, username, workspace path, or session identifier is included here.

The 125-130GB confirmations make this worth splitting into two tracks: safe user cleanup and product-side retention.

From the reports here, the large tree appears to be temporary macOS app clones under /private/var/folders/.../X/com.openai.codex.code_sign_clone, not ~/.codex, project workspaces, or normal Codex app support state. I would avoid broad app-cleaner deletion until the clone root is measured separately.

A low-risk evidence block for affected users:

root=$(find /private/var/folders -path "*/X/com.openai.codex.code_sign_clone" -type d 2>/dev/null | head -1)
echo "clone root: ${root:-not found}"

if [ -n "$root" ]; then
  du -sh "$root" 2>/dev/null
  find "$root" -maxdepth 1 -type d -name "code_sign_clone.*" 2>/dev/null | wc -l
  find "$root" -maxdepth 3 -type d -name "Codex.app.bundle" -print0 2>/dev/null \
    | xargs -0 du -sh 2>/dev/null \
    | sort -h \
    | tail -20
  lsof +D "$root" 2>/dev/null | head -40
fi

For cleanup, the narrow boundary I would use is: quit Codex, confirm lsof +D "$root" is empty, then move only code_sign_clone.* directories to Trash. Do not delete ~/.codex, workspaces, session files, credentials, or the whole app support folder as part of this workaround.

For the product fix, useful acceptance checks might be:

after N launch/quit cycles, inactive code_sign_clone.* dirs return to zero or a bounded count;
old clone dirs are removed when helper processes exit;
a startup self-check can warn if the clone tree exceeds a threshold like 5GB/10GB;
the app exposes the clone root in diagnostics without asking users to reveal private path segments.

I maintain a Mac storage cleanup tool, so I wrote the Codex-specific checklist here for anyone who wants the same commands without digging through the thread: https://www.getsafedisks.com/codex-code-sign-clone-disk-space-mac?utm_source=github&utm_medium=issue-comment&utm_campaign=codex-code-sign-clone-retention&utm_term=codex-macos-temp-clones&utm_content=openai-codex-25667

Same issue here on macOS 26.5.1 ... 13GB wasted in just a few days just for this issue.

Vibe coding is terrible 😆 this is yet another way for Codex to waste disk space... See #25921

I added a local macOS cron workaround for this.

The workaround runs hourly and cleans up leaked Codex code-sign clone directories under:

/private/var/folders/*/*/X/com.openai.codex.code_sign_clone/code_sign_clone.*

It keeps the newest birth-time group in each Codex temp parent and deletes only strictly older code_sign_clone.* directories. If multiple clone dirs have the same newest birth time, I keep all of them instead of guessing which one is safest to remove.

Cron entry:

0 * * * * /bin/bash "$HOME/dotfiles/utils/cleanup-codex-code-sign-clones.sh" >/dev/null 2>&1 || true

Script:

#!/usr/bin/env bash
set -euo pipefail

root="/private/var/folders"
dry_run=0
keep_count=1
stat_bin="${STAT_BIN:-/usr/bin/stat}"

while [ "$#" -gt 0 ]; do
  case "$1" in
    --root)
      root="$2"
      shift 2
      ;;
    --dry-run)
      dry_run=1
      shift
      ;;
    --keep)
      keep_count="$2"
      shift 2
      ;;
    *)
      echo "Unknown argument: $1" >&2
      exit 2
      ;;
  esac
done

root_abs="$(cd "$root" && pwd -P)"

is_safe_clone_dir() {
  local dir="$1"
  local dir_abs parent x_dir

  [ -d "$dir" ] || return 1
  dir_abs="$(cd "$dir" && pwd -P)"

  case "$dir_abs" in
    "$root_abs"/*/*/X/com.openai.codex.code_sign_clone/code_sign_clone.*) ;;
    *) return 1 ;;
  esac

  parent="$(dirname "$dir_abs")"
  x_dir="$(dirname "$parent")"
  [ "$(basename "$parent")" = "com.openai.codex.code_sign_clone" ] || return 1
  [ "$(basename "$x_dir")" = "X" ] || return 1
}

process_parent() {
  local parent="$1"
  local list_file="$2"
  local kept=0
  local keep_cutoff_birth=""
  local dir

  [ -d "$parent" ] || return 0

  : >"$list_file"
  while IFS= read -r -d '' dir; do
    if is_safe_clone_dir "$dir"; then
      printf '%s %s\n' "$("$stat_bin" -f '%B' "$dir")" "$dir" >>"$list_file"
    fi
  done < <(find "$parent" -maxdepth 1 -type d -name 'code_sign_clone.*' -print0)

  [ -s "$list_file" ] || return 0

  sort -k1,1nr "$list_file" | while IFS=' ' read -r birth dir; do
    if [ "$kept" -lt "$keep_count" ]; then
      kept=$((kept + 1))
      keep_cutoff_birth="$birth"
      echo "keep-newest $dir"
      continue
    fi

    if [ "$birth" = "$keep_cutoff_birth" ]; then
      echo "keep-tied-newest $dir"
      continue
    fi

    if [ "$dry_run" -eq 1 ]; then
      echo "delete $dir"
    else
      rm -rf "$dir"
      echo "deleted $dir"
    fi
  done
}

tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT

for parent in "$root_abs"/*/*/X/com.openai.codex.code_sign_clone; do
  process_parent "$parent" "$tmpdir/clones.$RANDOM"
done

I tested it against the real leaked directories on my machine. With three clone dirs present, it kept the newest one and removed the older two. A later dry run with one remaining clone dir reported that it would keep it.

Thanks for this issue opening. I finally know where my disk space gone.

#!/bin/bash
set -euo pipefail

TARGET="$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending"

[[ -d "$TARGET" ]] || { echo "Folder does not exist: $TARGET"; exit 0; }

/usr/bin/find "$TARGET" -maxdepth 1 -type f -delete >/dev/null 2>&1 || true
chmod -R a-w "$TARGET"

echo "Cleaned and made read-only: $TARGET"

ROOT="/private/var/folders"
NAME="com.openai.codex.code_sign_clone"

/usr/bin/find "$ROOT" -type d -name "$NAME" 2>/dev/null | while IFS= read -r dir; do
  echo "Found $dir"
  chmod -R u+w "$dir" 2>/dev/null || true
  /usr/bin/find "$dir" -mindepth 1 -delete 2>/dev/null || true
  chmod -R a-w "$dir" 2>/dev/null || true
  echo "Cleaned and made read-only: $dir"
done

Same issue here:

It took up over 23GB

Small safety note on the cron/read-only workarounds above:

The clone path here does look like temporary app clone state, but I would keep any workaround reversible. I would not make the clone parent, Crashpad pending folder, ~/.codex, or the app support folders permanently read-only. That can hide the symptom while breaking future launches, updates, crash reporting, or diagnostics.

Guardrails I would add before running this unattended:

run in dry-run mode first and log clone count, moved bytes, and the newest group that was kept;
quit Codex first, then skip the whole parent if lsof +D "$root" returns anything;
add a minimum-age guard, e.g. only move clone dirs older than 6-24 hours;
move older clone dirs to Trash or a staging folder, not rm -rf directly;
keep clone cleanup separate from Crashpad deletion, session cleanup, or app-support cleanup.

For this specific issue, SafeDisk Lite is not the authoritative scanner because /private/var/folders may sit outside the normal user-folder scan. The Codex-specific read-only checks are the important part. I updated the checklist with these guardrails here: https://www.getsafedisks.com/codex-code-sign-clone-disk-space-mac?utm_source=github&utm_medium=followup&utm_campaign=first-paid-cleanup&utm_term=codex-code-sign-clone-macos-temp-clones&utm_content=cron-readonly-safety-followup

Please someone fix this, had to make a LaunchAgent that looks for old clones in order to clean them

PS: This wouldn't happen if the app is open source :D

I can reproduce this on another Mac, and the impact is larger after several days of normal use.

Environment:

Codex App: 26.616.81150, CFBundleVersion 4306
macOS: 14.7.6 (23H626)
arch: arm64

Current Codex clone usage:

du -sh /private/var/folders/mh/v230pzl128v87fb3bc826kb80000gn/X/com.openai.codex.code_sign_clone

# 21G  /private/var/folders/mh/v230pzl128v87fb3bc826kb80000gn/X/com.openai.codex.code_sign_clone

Codex clone count:

find /private/var/folders/mh/v230pzl128v87fb3bc826kb80000gn/X/com.openai.codex.code_sign_clone \
  -maxdepth 1 -type d -name 'code_sign_clone.*' | wc -l

# 18

The Codex clone directories have mtimes across June 16-24, 2026, with several created on June 22-24. This matches the report: repeated app launches leave inactive code_sign_clone.* directories behind instead of cleaning them up, and it can consume tens of GB without the user installing anything.

Can confirm this issue as well, I've had to clean up space on my Mac multiple times, and the Codex app is always one of the biggest offenders, taking up gigabytes due to this.

Can confirm. I started to cleanup my 512GB macbook constantly because of this. I delete these directories and they come back as 30-50-sometimes even 70 GB.

This file takes up over 70 GB of disk space.

Navigation Menu

Repository navigation

[Bug] macOS app leaves code_sign_clone directories after quit (~965MB per launch) #25667

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug] macOS app leaves code_sign_clone directories after quit (~965MB per launch) #25667

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

pungaa commented on Jun 7, 2026

LZWcc commented on Jun 16, 2026

plxj6666 commented on Jun 17, 2026

VincentAdamNemessisX commented on Jun 19, 2026

liuminsheng3 commented on Jun 19, 2026

Jolg42 commented on Jun 20, 2026

Jolg42 commented on Jun 20, 2026

cyfung1031 commented on Jun 21, 2026

SameDesu123 commented on Jun 21, 2026

liuminsheng3 commented on Jun 22, 2026

ReyNeill commented on Jun 23, 2026

rszrszrsz commented on Jun 24, 2026

hourianto commented on Jun 24, 2026

emreertunc commented on Jun 24, 2026

init-center commented on Jun 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions