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

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!!!

<img width="400" height="96" alt="Image" src="https://github.com/user-attachments/assets/373e609a-cf46-40d6-af40-b40dbfc7215d" />

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.

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

<img width="615" height="318" alt="Image" src="https://github.com/user-attachments/assets/ef1e549c-472f-489b-af7d-8cff2f45db7c" />

Vibe coding is terrible 😆 this is yet another way for Codex to waste disk space... See https://github.com/openai/codex/issues/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.

<img width="399" height="141" alt="Image" src="https://github.com/user-attachments/assets/677474a5-f7cb-4a17-b0ff-f70ff523dc8c" />

#!/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:
<img width="274" height="94" alt="Image" src="https://github.com/user-attachments/assets/c1a6d253-aaa1-4a92-b35d-c151590bb3a0" />
It took up over 23GB

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.