Codex Desktop continuously generates Crashpad pending dumps, growing without any limit: +5GB per day at least

Update: I cleared the files inside the Crashpad pending directory after filing this issue.

Result immediately after cleanup:

before cleanup: 4.9G, 54,504 files
cleanup action: deleted files under ~/Library/Application Support/com.openai.codex/web/Crashpad/pending
immediate post-cleanup state: 6.4M, 70 files
post-cleanup split: 35 .dmp files, 35 _sidecar.json files

So the bulk of the disk usage was recoverable by deleting pending reports, but new paired dump/sidecar files appeared immediately afterward. That supports the earlier observation that Crashpad dump generation is still active, not just a stale historical backlog.

I did not attach any .dmp files publicly.

<img width="661" height="263" alt="Image" src="https://github.com/user-attachments/assets/bbcc1630-c67b-42a2-b3e2-e1eeb8932bad" />

Same here, mine reached 59GB🫠. Even though we've hit the 65535 file system limit, the background process is still relentlessly trying to dump more files.

I am seeing the same issue on macOS with a newer Codex Desktop build, with a bit more diagnostic detail.

Environment

• Product: Codex Desktop app on macOS
• Codex app version: 26.602.71036
• CFBundleVersion: 3685
• Framework/Crashpad annotation observed in dumps: ver=149.0.7827.54
• Architecture: arm64
• Crashpad database path:

~/Library/Application Support/com.openai.codex/web/Crashpad

Impact observed

The pending directory grew to about 61G:

~/Library/Application Support/com.openai.codex/web/Crashpad/pending

Counts from the pending directory before cleanup:

files: 738,864
.dmp files: 369,431
_sidecar.json files: 369,433
bytes: 63,233,668,274
GiB: 58.89
recent_24h files: 98,218
recent_7d files: 573,480
oldest: 2026-06-01 10:52:52
newest: 2026-06-09 10:00:26

After cleanup/reinstall/restart, the directory continued growing at roughly one crash report per second:

10:28:46 files=142 MiB=11.63
10:28:51 files=152 MiB=12.44
10:28:56 files=162 MiB=13.26
10:29:01 files=172 MiB=14.08
10:29:06 files=182 MiB=14.89

Key diagnostic detail

The newest .dmp files contain this FATAL message from browser_crashpad_handler itself:

browser_crashpad_handler
Codex_Mac
crashpad-handler
[0609/103121.674299:FATAL:third_party/crashpad/crashpad/handler/mac/exception_handler_server.cc:76]
Check failed: kr == KERN_SUCCESS.
mach_port_request_notification: (os/kern) invalid capability (20)
executable_path=/Applications/Codex.app/Contents/Frameworks/Codex Framework.framework/Versions/149.0.7827.54/Helpers/browser_crashpad_handler
--database=/Users/<user>/Library/Application Support/com.openai.codex/web/Crashpad
--annotation=prod=Codex_Mac

So in this case it looks like browser_crashpad_handler is crashing/restarting in a loop and writing paired .dmp / _sidecar.json files for itself.

System diagnostic logs also show repeated browser_crashpad_handler crashes with:

procName: browser_crashpad_handler
procPath: /Applications/Codex.app/Contents/Frameworks/Codex Framework.framework/Versions/149.0.7827.54/Helpers/browser_crashpad_handler
coalitionName: com.openai.codex
exception: EXC_BREAKPOINT / SIGTRAP

Related behavior

The in-app browser / Browser Use had previously become unavailable on this machine. During investigation, Codex logs repeatedly showed Browser Use / IAB lifecycle entries, and browser_use_availability_resolved available=true shortly before Crashpad kept generating dumps. That may or may not be the trigger, but the issue appears tied to the Codex Desktop browser/Chromium/Crashpad path.

A reinstall did not fix it.

Disabling browser@openai-bundled, disabling chrome@openai-bundled, and setting BROWSER_USE_AVAILABLE_BACKENDS = "" in ~/.codex/config.toml also did not stop the dump growth after restart.

Temporary workaround that stopped disk growth

Because macOS would not allow modifying /Applications/Codex.app/.../browser_crashpad_handler even with sudo (Operation not permitted), I worked around it by making the user Crashpad database read-only and immutable:

crash="$HOME/Library/Application Support/com.openai.codex/web/Crashpad"
pkill -f "browser_crashpad_handler.*com.openai.codex/web/Crashpad" 2>/dev/null || true
chflags -R nouchg "$crash" 2>/dev/null || true
chmod -R u+w "$crash" 2>/dev/null || true
rm -rf "$crash/pending" "$crash/new" "$crash/completed" "$crash/attachments"
mkdir -p "$crash/pending" "$crash/new" "$crash/completed" "$crash/attachments"
chmod -R 555 "$crash"
chflags -R uchg "$crash"

After that, pending stayed at zero for the observed window:

10:40:12 files=0 MiB=0.0
10:40:17 files=0 MiB=0.0
10:40:22 files=0 MiB=0.0
10:40:27 files=0 MiB=0.0
10:40:32 files=0 MiB=0.0
10:40:37 files=0 MiB=0.0
10:40:42 files=0 MiB=0.0
10:40:47 files=0 MiB=0.0

This is only a disk-growth workaround, not a real fix, since it effectively prevents Codex from writing Crashpad reports.

I am too, just cleaned up 22G today

same issue on version 26.601.10930. cc @dnakov

I think this is fixed with later macos versions. at least in 26.5 it is

I ran into this exact same issue. Oh my god, no wonder my Mac's storage keeps getting full. Is Codex Desktop just a mountain of garbage code OpenAI built via vibe coding?

Both Claude and Codex have ZERO RESPECT for user's machines. Holy hell.

every json just 2 bytes+ 150KB, but the more serious thing behind is that, there are crash reports continously generating in /System/Library/Caches/com.apple.coresymbolicationd/data

<img width="688" height="442" alt="Image" src="https://github.com/user-attachments/assets/19e5ca7e-6476-44a5-84d2-43f14b61ea55" />

use this script to check your macOS.

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

# recent-files.sh
#
# Usage:
#   ./recent-files.sh [directory] [hours]
#
# Examples:
#   ./recent-files.sh
#   ./recent-files.sh / 24
#   sudo ./recent-files.sh / 168
#
# Environment:
#   PAGE_SIZE=500 ./recent-files.sh / 24
#   FORCE_SCAN=1 ./recent-files.sh / 24   # macOS: bypass Spotlight and scan

DIR="${1:-.}"
HOURS="${2:-24}"
PAGE_SIZE="${PAGE_SIZE:-1000}"
FORCE_SCAN="${FORCE_SCAN:-0}"

if [[ ! -d "$DIR" ]]; then
  echo "Error: '$DIR' is not a directory"
  exit 1
fi

if ! [[ "$HOURS" =~ ^[0-9]+$ ]]; then
  echo "Error: hours must be a positive integer"
  exit 1
fi

if ! [[ "$PAGE_SIZE" =~ ^[0-9]+$ ]]; then
  echo "Error: PAGE_SIZE must be a positive integer"
  exit 1
fi

TMP="$(mktemp "${TMPDIR:-/tmp}/recent-files.XXXXXX")"
trap 'rm -f "$TMP"' EXIT

PAGE=0

is_gnu_find() {
  find --version >/dev/null 2>&1
}

is_macos() {
  [[ "$(uname -s)" == "Darwin" ]]
}

index_linux_gnu_find() {
  local minutes=$((HOURS * 60))

  # Output fields:
  # sort_epoch | size | added_date | modified_date | file_path
  find "$DIR" \
    -type f \
    -mmin "-$minutes" \
    -printf '%T@\t%s\t%w\t%TY-%Tm-%Td %TH:%TM:%TS\t%p\n' \
    2>/dev/null \
    | sort -nr > "$TMP"
}

index_macos_spotlight() {
  local cutoff_iso
  cutoff_iso="$(date -v-"${HOURS}"H '+%Y-%m-%d %H:%M:%S')"

  # Spotlight is indexed and very fast, but may exclude some system/protected areas.
  # kMDItemFSContentChangeDate = modified/change date.
  mdfind -onlyin "$DIR" \
    "kMDItemFSContentChangeDate >= \$time.iso($cutoff_iso)" \
    2>/dev/null \
    | while IFS= read -r file; do
        [[ -f "$file" ]] || continue

        mtime_epoch="$(stat -f '%m' "$file" 2>/dev/null)" || continue
        size="$(stat -f '%z' "$file" 2>/dev/null || echo "-")"
        added="$(stat -f '%SB' -t '%Y-%m-%d %H:%M:%S' "$file" 2>/dev/null || echo "-")"
        modified="$(stat -f '%Sm' -t '%Y-%m-%d %H:%M:%S' "$file" 2>/dev/null || echo "-")"

        printf '%s\t%s\t%s\t%s\t%s\n' \
          "$mtime_epoch" "$size" "$added" "$modified" "$file"
      done \
      | sort -nr > "$TMP"
}

index_macos_full_scan() {
  local now cutoff
  now="$(date +%s)"
  cutoff=$((now - HOURS * 3600))

  # Slower than Spotlight, but searches actual filesystem paths recursively.
  find "$DIR" -type f -print0 2>/dev/null \
    | while IFS= read -r -d '' file; do
        mtime_epoch="$(stat -f '%m' "$file" 2>/dev/null)" || continue
        (( mtime_epoch >= cutoff )) || continue

        size="$(stat -f '%z' "$file" 2>/dev/null || echo "-")"
        added="$(stat -f '%SB' -t '%Y-%m-%d %H:%M:%S' "$file" 2>/dev/null || echo "-")"
        modified="$(stat -f '%Sm' -t '%Y-%m-%d %H:%M:%S' "$file" 2>/dev/null || echo "-")"

        printf '%s\t%s\t%s\t%s\t%s\n' \
          "$mtime_epoch" "$size" "$added" "$modified" "$file"
      done \
      | sort -nr > "$TMP"
}

build_index() {
  : > "$TMP"

  echo "Indexing recent files..."
  echo "Directory: $DIR"
  echo "Recent window: last $HOURS hour(s)"
  echo

  if is_gnu_find; then
    index_linux_gnu_find
  elif is_macos && command -v mdfind >/dev/null 2>&1 && [[ "$FORCE_SCAN" != "1" ]]; then
    index_macos_spotlight
  else
    index_macos_full_scan
  fi

  local count
  count="$(wc -l < "$TMP" | tr -d ' ')"

  if [[ "$count" == "0" ]]; then
    echo "No recent files found."
    echo
    echo "Tips:"
    echo "  - Try a larger window: ./recent-files.sh '$DIR' 168"
    echo "  - Search from root: sudo ./recent-files.sh / 24"
    echo "  - On macOS, force real scan: FORCE_SCAN=1 ./recent-files.sh '$DIR' 24"
    exit 0
  fi
}

print_page() {
  local start end total

  total="$(wc -l < "$TMP" | tr -d ' ')"
  start=$((PAGE * PAGE_SIZE + 1))
  end=$((start + PAGE_SIZE - 1))

  clear
  echo "Directory: $DIR"
  echo "Recent window: last $HOURS hour(s)"
  echo "Total files found: $total"
  echo "Page: $((PAGE + 1))"
  echo "Showing: $start-$end"
  echo

  printf "%-12s | %-19s | %-19s | %s\n" \
    "Size(bytes)" "Added date" "Modified date" "File"
  printf "%-12s-+-%-19s-+-%-19s-+-%s\n" \
    "------------" "-------------------" "-------------------" "------------------------------"

  sed -n "${start},${end}p" "$TMP" \
    | awk -F '\t' '{
        # $1 = sort epoch
        # $2 = size
        # $3 = added date
        # $4 = modified date
        # $5+ = file path, in case path somehow contains tabs
        file=$5
        for (i=6; i<=NF; i++) file=file "\t" $i

        sub(/\..*/, "", $3)
        sub(/\..*/, "", $4)

        printf "%-12s | %-19s | %-19s | %s\n", $2, $3, $4, file
      }'
}

build_index

while true; do
  print_page

  echo
  echo "[n] next page | [p] previous page | [r] rebuild | [q] quit"
  read -r -p "Choice: " choice

  case "$choice" in
    n|N)
      PAGE=$((PAGE + 1))
      ;;
    p|P)
      (( PAGE > 0 )) && PAGE=$((PAGE - 1))
      ;;
    r|R)
      PAGE=0
      build_index
      ;;
    q|Q)
      exit 0
      ;;
    *)
      echo "Unknown choice."
      sleep 1
      ;;
  esac
done

<img width="791" height="573" alt="Image" src="https://github.com/user-attachments/assets/8a6e808d-6fd5-47bf-93c2-542f544daed2" />

---

script to view and clean the crash reports

#!/bin/bash

TARGET_DIR="/System/Library/Caches/com.apple.coresymbolicationd"
TARGET_DATA="$TARGET_DIR/data"

show_menu() {
  echo
  echo "macOS coresymbolicationd cache tool"
  echo "Target: $TARGET_DIR"
  echo
  echo "1) View / check files inside com.apple.coresymbolicationd"
  echo "2) Clean up com.apple.coresymbolicationd cache"
  echo "q) Quit"
  echo
}

view_cache() {
  echo
  echo "Checking: $TARGET_DIR"
  echo

  if [ ! -d "$TARGET_DIR" ]; then
    echo "Directory not found: $TARGET_DIR"
    return
  fi

  echo "Total size:"
  sudo du -sh "$TARGET_DIR" 2>/dev/null || echo "Unable to read size. Try running with sudo."
  echo

  echo "Files:"
  sudo ls -lah "$TARGET_DIR"
  echo

  if [ -f "$TARGET_DATA" ]; then
    echo "Main data file:"
    sudo ls -lh "$TARGET_DATA"
    echo

    echo "Approx size in GB:"
    sudo du -g "$TARGET_DATA" 2>/dev/null
  else
    echo "No data file found at: $TARGET_DATA"
  fi

  echo
  echo "Recently modified items:"
  sudo find "$TARGET_DIR" -maxdepth 2 -type f -print0 2>/dev/null \
    | sudo xargs -0 ls -lt 2>/dev/null \
    | head -20
}

clean_cache() {
  echo
  echo "This will delete files inside:"
  echo "$TARGET_DIR"
  echo
  echo "It will NOT delete the folder itself."
  echo "macOS should recreate the cache when needed."
  echo

  read -r -p "Type CLEAN to continue: " confirm

  if [ "$confirm" != "CLEAN" ]; then
    echo "Cancelled."
    return
  fi

  echo
  echo "Stopping coresymbolicationd if running..."
  sudo killall coresymbolicationd 2>/dev/null || true

  echo "Deleting cache contents..."
  if [ -d "$TARGET_DIR" ]; then
    sudo find "$TARGET_DIR" -mindepth 1 -maxdepth 1 -exec rm -rf {} +
    echo "Cleanup complete."
  else
    echo "Directory not found: $TARGET_DIR"
  fi

  echo
  echo "Current size:"
  sudo du -sh "$TARGET_DIR" 2>/dev/null || echo "Cache directory may not exist until macOS recreates it."

  echo
  echo "Tip: reboot if the storage number in System Settings does not update immediately."
}

while true; do
  show_menu
  read -r -p "Choose an option: " choice

  case "$choice" in
    1)
      view_cache
      ;;
    2)
      clean_cache
      ;;
    q|Q)
      echo "Bye."
      exit 0
      ;;
    *)
      echo "Invalid option."
      ;;
  esac
done

---

after deleting, try delete this as well to reset Codex.

~/Library/Saved Application State/com.openai.codex.savedState

I hit what appears to be the same Crashpad pending-dump growth issue, but at a much larger scale.

Environment

• Product: Codex Desktop app on macOS
• Codex app version: 26.611.62324
• CFBundleVersion: 4028
• macOS: 15.6 (24G84)
• Architecture: arm64
• Current helper/Crashpad annotation observed from live process path: Electron/Chromium helper 149.0.7827.115

Observed disk usage

The large growth was under the legacy app-data path:

~/Library/Application Support/com.openai.codex/web/Crashpad/pending

Before cleanup, this directory contained:

1,786,086 total entries
893,043 .dmp files
893,043 _sidecar.json files
147,440,897,945 bytes total
137.32 GiB total
137.31 GiB from .dmp files

File time range:

oldest: 2026-06-01 11:55:53
newest: 2026-06-18 14:16:58

Daily distribution included multiple days above 13 GiB:

2026-06-06  13.17 GiB
2026-06-07  13.18 GiB
2026-06-08  13.18 GiB
2026-06-12  13.14 GiB
2026-06-13  13.17 GiB
2026-06-14  13.17 GiB
2026-06-15  11.66 GiB
2026-06-18   7.82 GiB

Largest observed dump files were still relatively small:

782,272 bytes
739,984 bytes
705,456 bytes

So the disk growth was caused by hundreds of thousands of small crash dumps, not a few large files.

Cleanup result

After deleting pending files, the legacy path is now empty:

~/Library/Application Support/com.openai.codex/web/Crashpad/pending
count=0
total_mib=0.00

The currently running Codex app appears to use a different app-data path:

~/Library/Application Support/Codex/Crashpad

Current size there is small:

~/Library/Application Support/Codex                 223M
~/Library/Application Support/Codex/Crashpad         20K
~/Library/Application Support/Codex/Crashpad/pending 16K
pending count=4

That path difference may be relevant: the unbounded growth happened under com.openai.codex/web/Crashpad, while the current running app uses Codex/Crashpad.

I am not attaching .dmp files publicly because they may contain private memory, paths, or local state. I can collect additional metadata or share a dump through a safe maintainer-provided upload path if useful.

My temporary macOS workaround:

I’m clearing Codex’s pending Crashpad reports every 15 minutes to avoid the local buildup:

*/15 * * * * /usr/bin/find "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f -delete >/dev/null 2>&1 || true

Setup on macOS:
crontab -e

Add the cron line above, save, then verify:
crontab -l

This deletes only files directly inside:
~/Library/Application Support/com.openai.codex/web/Crashpad/pending

In case you also have that problem, there is yet another way this vibe coded app wastes disk space for me, see https://github.com/openai/codex/issues/25667#issuecomment-4758527276

I found a method which seems working well. clean up the folder as mentioned by @Jolg42 , then set it read-only.
I tested few hours. Now Codex cannot write any trash to this folder any more.

Crashpad/pending/ only

#!/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; }

echo "Found $TARGET"
/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"

Crashpad/pending/ + com.openai.codex.code_sign_clone

#!/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; }

echo "Found $TARGET"
/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

This is a serious problem, it is rapidly damaging hardware in computers where memory is not replaceable. It must be fixed asap.