Codex is EATING my Mac's disk space
Codex Desktop continuously generates Crashpad pending dumps, growing without any limit: +5GB per day at least #25921 Description Summary Codex Desktop is continuously adding paired .dmp and _sidecar.json files under: ~/Library/Application Support/com.openai.codex/web/Crashpad/pending On my machine this directory grew to 4.9G and 54,504 files in one day. The count continued increasing during investigation, so this appears to be active Crashpad dump generation rather than stale one-time leftovers. The Codex Desktop app is still functional while this is happening. I can use the app, inspect the filesystem, and interact with GitHub from the same running session. So the user-visible problem is not that Codex is fully crashing or unable to launch. The issue is that Crashpad is continuously generating pending dump/sidecar pairs in the background while the app remains usable, causing unbounded local disk growth. I am not attaching minidumps publicly because they may contain memory, local paths, or private data. I can share the newest .dmp privately if OpenAI maintainers provide a safe upload path. Environment Product: Codex Desktop app on macOS Codex app version: 26.527.60818 CFBundleVersion: 3437 Crashpad/Electron annotation observed from live process: prod=Codex_Mac, ver=148.0.7778.179 macOS: 26.3.1 (25D771280a) Architecture: arm64 Observed evidence Crashpad pending directory: ~/Library/Application Support/com.openai.codex/web/Crashpad/pending Latest measurements: 4.9G ~/Library/Application Support/com.openai.codex/web/Crashpad/pending 54,504 files total 27,252 .dmp files 27,252 _sidecar.json files Sampled pending file time range: oldest sampled pending files: 2026-06-02 13:31:21 CEST latest sampled pending files: 2026-06-02 21:08:24 CEST During the investigation the count increased from 53,444 to 54,064, then to 54,504, which indicates the queue was still growing. I also observed two Codex browser_crashpad_handler processes running under PPID=1 since Sat May 30 11:47:50 2026, both using the same Crashpad database: /Applications/Codex.app/.../Helpers/browser_crashpad_handler \ --database=~/Library/Application Support/com.openai.codex/web/Crashpad \ --annotation=plat=OS X \ --annotation=prod=Codex_Mac \ --annotation=ver=148.0.7778.179 The local app remained usable enough to inspect/report this, so the visible issue is not just a normal foreground app crash. It looks like Crashpad or a monitored helper process is repeatedly generating pending dumps without bounding, upload/processing cleanup, or rotation. Expected behavior Crash reports should be bounded, uploaded/processed/rotated, or not continuously generated while the app remains usable. Actual behavior Pending Crashpad reports accumulate rapidly and consume multiple GB of local disk space. Commands used to collect evidence du -sh "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" find "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f | wc -l find "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f \ | sed 's/.*\.//' | sort | uniq -c | sort -nr /usr/libexec/PlistBuddy -c 'Print :CFBundleShortVersionString' /Applications/Codex.app/Contents/Info.plist /usr/libexec/PlistBuddy -c 'Print :CFBundleVersion' /Applications/Codex.app/Contents/Info.plist sw_vers uname -m ps ax -o pid,ppid,lstart,command \ | grep -E 'browser_crashpad_handler|com.openai.codex/web/Crashpad' \ | grep -v grep Related issues This may be related to other Codex Desktop helper/process cleanup reports: Codex App update left old crashpad helper; relaunch could no-op until clean restart #25259: stale Crashpad helper after update/relaunch Codex App UI freezes: worker crashes, massive git/worktree errors, and concurrent orphaned app-server processes #11090: orphaned Codex processes and UI freezes Can't open app in Tahoe 26.2 (25C56) #10627: prior Crashpad/macOS startup reports Activity github-actions added bugSomething isn't workingSomething isn't working appIssues related to the Codex desktop appIssues related to the Codex desktop app performance on Jun 2, 2026 Jolg42 commented on Jun 2, 2026 Jolg42 on Jun 2, 2026 – with ChatGPT Codex Connector Author More actions 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. Jolg42 commented on Jun 2, 2026 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. mxggle commented on Jun 7, 2026 mxggle on Jun 7, 2026 More actions 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. 😕React with 😕2Reacted by Dmytro Karpovych and Glenn 'devalias' Grant mxggle commented on Jun 7, 2026 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. dionylon commented on Jun 9, 2026 dionylon on Jun 9, 2026 More actions 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/
/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. 👍React with 👍1Reacted by ai-poet dionylon commented on Jun 9, 2026 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/
/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. Cuimc commented on Jun 9, 2026 Cuimc on Jun 9, 2026 More actions I am too, just cleaned up 22G today Cuimc commented on Jun 9, 2026 I am too, just cleaned up 22G today Jolg42 changed the title [-]Codex Desktop continuously generates Crashpad pending dumps, growing to ~5GB[/-] [+]Codex Desktop continuously generates Crashpad pending dumps, growing without any limit: +5GB per day at least[/+] on Jun 9, 2026 changjonathanc commented on Jun 13, 2026 changjonathanc on Jun 13, 2026 More actions same issue on version 26.601.10930. cc @dnakov changjonathanc commented on Jun 13, 2026 same issue on version 26.601.10930. cc @dnakov dnakov commented on Jun 14, 2026 dnakov on Jun 14, 2026 Contributor More actions I think this is fixed with later macos versions. at least in 26.5 it is 👍React with 👍1Reacted by Jonathan Chang dnakov commented on Jun 14, 2026 I think this is fixed with later macos versions. at least in 26.5 it is ai-poet commented on Jun 17, 2026 ai-poet on Jun 17, 2026 Last edited by ai-poet More actions 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? 👍React with 👍1Reacted by jordanade ai-poet commented on Jun 17, 2026 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? jordanade commented on Jun 17, 2026 jordanade on Jun 17, 2026 More actions Both Claude and Codex have ZERO RESPECT for user's machines. Holy hell. 👍React with 👍2Reacted by louie-lou and James Power jordanade commented on Jun 17, 2026 Both Claude and Codex have ZERO RESPECT for user's machines. Holy hell. cyfung1031 commented on Jun 18, 2026 cyfung1031 on Jun 18, 2026 Last edited by cyfung1031 More actions 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 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 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 cyfung1031 commented on Jun 18, 2026 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 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 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 guojianlan commented on Jun 18, 2026 guojianlan on Jun 18, 2026 More actions 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. guojianlan commented on Jun 18, 2026 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. liuminsheng3 commented on Jun 19, 2026 liuminsheng3 on Jun 19, 2026 Last edited by liuminsheng3 More actions For anyone still trying to distinguish "old backlog" from "active dump loop", I would measure both Codex app-data paths separately before deleting broader app state: paths=( "$HOME/Library/Application Support/com.openai.codex/web/Crashpad" "$HOME/Library/Application Support/Codex/Crashpad" ) for crash in "${paths[@]}"; do echo "== $crash ==" [ -d "$crash" ] || { echo "missing"; continue; } du -sh "$crash" "$crash/pending" 2>/dev/null find "$crash/pending" -maxdepth 1 -type f 2>/dev/null | wc -l find "$crash/pending" -maxdepth 1 -type f -name '*.dmp' 2>/dev/null | wc -l find "$crash/pending" -maxdepth 1 -type f -name '*_sidecar.json' 2>/dev/null | wc -l find "$crash/pending" -maxdepth 1 -type f -print0 2>/dev/null \ | xargs -0 stat -f '%Sm %z %N' -t '%Y-%m-%d %H:%M:%S' 2>/dev/null \ | sort | sed -n '1p;$p' done For cleanup, I would avoid deleting the whole Application Support/Codex directory unless a full local reset is intended. A narrower recovery path is: Quit Codex. Stop any Codex Crashpad handler that is still writing to that Crashpad database. Move only Crashpad report buckets such as pending, new, completed, and attachments to Trash. Restart Codex and watch the pending count for a few minutes. Example Trash-only version: osascript -e 'quit app "Codex"' 2>/dev/null || true pkill -f "browser_crashpad_handler.*codex.*/Crashpad" 2>/dev/null || true for crash in \ "$HOME/Library/Application Support/com.openai.codex/web/Crashpad" \ "$HOME/Library/Application Support/Codex/Crashpad"; do [ -d "$crash" ] || continue mkdir -p "$HOME/.Trash/Codex-Crashpad" for bucket in pending new completed attachments; do [ -d "$crash/$bucket" ] || continue find "$crash/$bucket" -mindepth 1 -maxdepth 1 -exec mv {} "$HOME/.Trash/Codex-Crashpad/" \; done done I would not attach .dmp files publicly; they may contain memory, local paths, prompts, or project state. Metadata like counts, size, oldest/newest timestamp, app version, and which path is still growing should be enough for most public triage. Disclosure: I maintain SafeDisk, a local-first storage cleanup/checklist project. I wrote up this specific Crashpad cleanup boundary here: https://www.getsafedisks.com/codex-crashpad-pending-dumps-disk-space?utm_source=github&utm_medium=issue-comment&utm_campaign=codex-crashpad-disk-space&utm_term=codex-crashpad-pending-dumps&utm_content=openai-codex-25921 If someone wants a private second read before deleting app state, that page now has a single on-page Deep Cleanup request form after the read-only checks. liuminsheng3 commented on Jun 19, 2026 For anyone still trying to distinguish "old backlog" from "active dump loop", I would measure both Codex app-data paths separately before deleting broader app state: paths=( "$HOME/Library/Application Support/com.openai.codex/web/Crashpad" "$HOME/Library/Application Support/Codex/Crashpad" ) for crash in "${paths[@]}"; do echo "== $crash ==" [ -d "$crash" ] || { echo "missing"; continue; } du -sh "$crash" "$crash/pending" 2>/dev/null find "$crash/pending" -maxdepth 1 -type f 2>/dev/null | wc -l find "$crash/pending" -maxdepth 1 -type f -name '*.dmp' 2>/dev/null | wc -l find "$crash/pending" -maxdepth 1 -type f -name '*_sidecar.json' 2>/dev/null | wc -l find "$crash/pending" -maxdepth 1 -type f -print0 2>/dev/null \ | xargs -0 stat -f '%Sm %z %N' -t '%Y-%m-%d %H:%M:%S' 2>/dev/null \ | sort | sed -n '1p;$p' done For cleanup, I would avoid deleting the whole Application Support/Codex directory unless a full local reset is intended. A narrower recovery path is: Quit Codex. Stop any Codex Crashpad handler that is still writing to that Crashpad database. Move only Crashpad report buckets such as pending, new, completed, and attachments to Trash. Restart Codex and watch the pending count for a few minutes. Example Trash-only version: osascript -e 'quit app "Codex"' 2>/dev/null || true pkill -f "browser_crashpad_handler.*codex.*/Crashpad" 2>/dev/null || true for crash in \ "$HOME/Library/Application Support/com.openai.codex/web/Crashpad" \ "$HOME/Library/Application Support/Codex/Crashpad"; do [ -d "$crash" ] || continue mkdir -p "$HOME/.Trash/Codex-Crashpad" for bucket in pending new completed attachments; do [ -d "$crash/$bucket" ] || continue find "$crash/$bucket" -mindepth 1 -maxdepth 1 -exec mv {} "$HOME/.Trash/Codex-Crashpad/" \; done done I would not attach .dmp files publicly; they may contain memory, local paths, prompts, or project state. Metadata like counts, size, oldest/newest timestamp, app version, and which path is still growing should be enough for most public triage. Disclosure: I maintain SafeDisk, a local-first storage cleanup/checklist project. I wrote up this specific Crashpad cleanup boundary here: https://www.getsafedisks.com/codex-crashpad-pending-dumps-disk-space?utm_source=github&utm_medium=issue-comment&utm_campaign=codex-crashpad-disk-space&utm_term=codex-crashpad-pending-dumps&utm_content=openai-codex-25921 If someone wants a private second read before deleting app state, that page now has a single on-page Deep Cleanup request form after the read-only checks. Jolg42 commented on Jun 20, 2026 Jolg42 on Jun 20, 2026 Author More actions 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 Jolg42 commented on Jun 20, 2026 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 Jolg42 commented on Jun 20, 2026 Jolg42 on Jun 20, 2026 Author More actions In case you also have that problem, there is yet another way this vibe coded app wastes disk space for me, see #25667 (comment) Jolg42 commented on Jun 20, 2026 In case you also have that problem, there is yet another way this vibe coded app wastes disk space for me, see #25667 (comment) cyfung1031 commented on Jun 21, 2026 cyfung1031 on Jun 21, 2026 Last edited by cyfung1031 More actions 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 cyfung1031 commented on Jun 21, 2026 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 liuminsheng3 commented on Jun 22, 2026 liuminsheng3 on Jun 22, 2026 More actions One caution on the chmod / read-only workaround above: I would treat it as an emergency brake, not the default cleanup path. Making only Crashpad/pending read-only can stop an active dump loop, but it also prevents Codex from writing crash reports and may hide the signal maintainers need. I would keep the scope narrow and avoid making these broader paths permanently read-only: ~/Library/Application Support/Codex ~/Library/Application Support/com.openai.codex temporary com.openai.codex.code_sign_clone directories My safer order would be: Quit Codex. Move only Crashpad report buckets such as pending, new, completed, and attachments to Trash. Restart Codex and watch whether pending starts growing again. Use a read-only workaround only if it is actively refilling and you need to stop disk loss immediately. Undo the read-only bit after the app/version issue is fixed. I updated the checklist here with the narrower warning and a small rollback snippet: https://www.getsafedisks.com/codex-crashpad-pending-dumps-disk-space?utm_source=github&utm_medium=followup&utm_campaign=first-paid-cleanup&utm_term=codex-crashpad-pending-dumps-disk-space&utm_content=readonly-safety-followup liuminsheng3 commented on Jun 22, 2026 One caution on the chmod / read-only workaround above: I would treat it as an emergency brake, not the default cleanup path. Making only Crashpad/pending read-only can stop an active dump loop, but it also prevents Codex from writing crash reports and may hide the signal maintainers need. I would keep the scope narrow and avoid making these broader paths permanently read-only: ~/Library/Application Support/Codex ~/Library/Application Support/com.openai.codex temporary com.openai.codex.code_sign_clone directories My safer order would be: Quit Codex. Move only Crashpad report buckets such as pending, new, completed, and attachments to Trash. Restart Codex and watch whether pending starts growing again. Use a read-only workaround only if it is actively refilling and you need to stop disk loss immediately. Undo the read-only bit after the app/version issue is fixed. I updated the checklist here with the narrower warning and a small rollback snippet: https://www.getsafedisks.com/codex-crashpad-pending-dumps-disk-space?utm_source=github&utm_medium=followup&utm_campaign=first-paid-cleanup&utm_term=codex-crashpad-pending-dumps-disk-space&utm_content=readonly-safety-followup Eseperio commented on Jul 16, 2026 Eseperio on Jul 16, 2026 More actions This is a serious problem, it is rapidly damaging hardware in computers where memory is not replaceable. It must be fixed asap. 👍React with 👍5Reacted by Phuwanai Thummavet, kou kumotora, whatcall, WilsonPiper and Ahmed Khan Eseperio commented on Jul 16, 2026 This is a serious problem, it is rapidly damaging hardware in computers where memory is not replaceable. It must be fixed asap. libairi commented on Jul 21, 2026 libairi on Jul 21, 2026 More actions Still reproducible in the current unified ChatGPT/Codex desktop app, with the newer Crashpad database path. Environment App: ChatGPT unified desktop app (com.openai.codex) App version: 26.715.70719 Build: 5650 macOS: 15.7.4 (24G517) Architecture: Apple Silicon / arm64 Chromium framework: 150.0.7871.124 Crashpad database: ~/Library/Application Support/Codex/Crashpad Impact Crashpad/pending reached approximately 33.4 GiB. About 23.3 GiB had been generated during the last three days. Deleting pending reports recovered the disk space, but new paired dumps/sidecars began appearing immediately. The main ChatGPT window can remain alive while browser_crashpad_handler crashes and respawns repeatedly. macOS retained at least 50 handler crash reports on 2026-07-20 and 43 on 2026-07-21; the real number of Crashpad pending dumps was much higher. Exact handler failure [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) The macOS .ips reports show: procName: browser_crashpad_handler responsibleProc: ChatGPT exception: EXC_BREAKPOINT / SIGTRAP procPath: /Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/150.0.7871.124/Helpers/browser_crashpad_handler The earliest retained report on this machine is from 2026-07-20 08:17:09 +0800, before build 5650 was installed on this machine. Its handler UUID is 4C4C44FF-5555-3144-A167-DF0A5F297DB2. I also downloaded the official build 5538 (26.715.31251) and compared its handler with build 5650. Both use Chromium 150.0.7871.124, have the same Mach-O UUID, and have an identical SHA-256 hash for the unsigned code region. Therefore rolling back only to build 5538 is unlikely to avoid this failure. Workarounds tested Launching with --disable-breakpad: did not prevent new Crashpad reports. Denying execution of the handler: stopped pending dumps but caused repeated macOS “ChatGPT quit unexpectedly” reports/popups, so this is not viable. Periodically deleting only Crashpad/pending: contains disk usage but does not fix the handler crash loop. No .dmp file is attached because it may contain private process memory. I can provide sanitized metadata or use a maintainer-provided private upload channel if needed. Could the desktop app either fix the handler startup/monitor-self failure, honor a supported crash-reporting opt-out, or enforce a strict retention/size limit on pending dumps? libairi commented on Jul 21, 2026 Still reproducible in the current unified ChatGPT/Codex desktop app, with the newer Crashpad database path. Environment App: ChatGPT unified desktop app (com.openai.codex) App version: 26.715.70719 Build: 5650 macOS: 15.7.4 (24G517) Architecture: Apple Silicon / arm64 Chromium framework: 150.0.7871.124 Crashpad database: ~/Library/Application Support/Codex/Crashpad Impact Crashpad/pending reached approximately 33.4 GiB. About 23.3 GiB had been generated during the last three days. Deleting pending reports recovered the disk space, but new paired dumps/sidecars began appearing immediately. The main ChatGPT window can remain alive while browser_crashpad_handler crashes and respawns repeatedly. macOS retained at least 50 handler crash reports on 2026-07-20 and 43 on 2026-07-21; the real number of Crashpad pending dumps was much higher. Exact handler failure [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) The macOS .ips reports show: procName: browser_crashpad_handler responsibleProc: ChatGPT exception: EXC_BREAKPOINT / SIGTRAP procPath: /Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/150.0.7871.124/Helpers/browser_crashpad_handler The earliest retained report on this machine is from 2026-07-20 08:17:09 +0800, before build 5650 was installed on this machine. Its handler UUID is 4C4C44FF-5555-3144-A167-DF0A5F297DB2. I also downloaded the official build 5538 (26.715.31251) and compared its handler with build 5650. Both use Chromium 150.0.7871.124, have the same Mach-O UUID, and have an identical SHA-256 hash for the unsigned code region. Therefore rolling back only to build 5538 is unlikely to avoid this failure. Workarounds tested Launching with --disable-breakpad: did not prevent new Crashpad reports. Denying execution of the handler: stopped pending dumps but caused repeated macOS “ChatGPT quit unexpectedly” reports/popups, so this is not viable. Periodically deleting only Crashpad/pending: contains disk usage but does not fix the handler crash loop. No .dmp file is attached because it may contain private process memory. I can provide sanitized metadata or use a maintainer-provided private upload channel if needed. Could the desktop app either fix the handler startup/monitor-self failure, honor a supported crash-reporting opt-out, or enforce a strict retention/size limit on pending dumps? jakehop commented on Aug 9, 2026 jakehop on Aug 9, 2026 More actions Same issue here. The crazy thing is that a pruner does ship with Crashpad, but it's not implemented here. I've seen this behaviour in other Electron apps, where the handler is wired up but the pruner is not, and if telemetry is turned off or blocked, these logs will just pile up in pending. jakehop commented on Aug 9, 2026 Same issue here. The crazy thing is that a pruner does ship with Crashpad, but it's not implemented here. I've seen this behaviour in other Electron apps, where the handler is wired up but the pruner is not, and if telemetry is turned off or blocked, these logs will just pile up in pending. austinhutchison commented on Aug 15, 2026 austinhutchison on Aug 15, 2026 – with ChatGPT Codex Connector More actions I’m seeing the same Crashpad pending-report growth on the current unified ChatGPT/Codex desktop app. Environment: App: ChatGPT desktop app with Codex App version: 26.803.61601 Build: 6396 macOS: 26.3.1 (25D771280a) Architecture: arm64 The affected path is: ~/Library/Application Support/Codex/Crashpad/pending This directory grew to approximately 100 GB and roughly one million files. The files appear to be Crashpad pending reports, including .dmp files and sidecar metadata. The app remained usable while the directory grew. This appears to be the newer Codex/Crashpad path rather than the older: ~/Library/Application Support/com.openai.codex/web/Crashpad/pending Deleting or moving the contents of Crashpad/pending recovers the disk space, but I have not yet established whether the directory regrows after cleanup. Could someone clarify whether the comment that “later macOS versions, at least 26.5,” fix this refers to a known macOS fix? If so, is macOS 26.5 expected to prevent the Crashpad handler failure, or is a Codex app update also required? I have not attached dump files because they may contain process memory, local paths, or other private data. I can provide sanitized counts, timestamps, or logs if that would help diagnose it. austinhutchison commented on Aug 15, 2026 I’m seeing the same Crashpad pending-report growth on the current unified ChatGPT/Codex desktop app. Environment: App: ChatGPT desktop app with Codex App version: 26.803.61601 Build: 6396 macOS: 26.3.1 (25D771280a) Architecture: arm64 The affected path is: ~/Library/Application Support/Codex/Crashpad/pending This directory grew to approximately 100 GB and roughly one million files. The files appear to be Crashpad pending reports, including .dmp files and sidecar metadata. The app remained usable while the directory grew. This appears to be the newer Codex/Crashpad path rather than the older: ~/Library/Application Support/com.openai.codex/web/Crashpad/pending Deleting or moving the contents of Crashpad/pending recovers the disk space, but I have not yet established whether the directory regrows after cleanup. Could someone clarify whether the comment that “later macOS versions, at least 26.5,” fix this refers to a known macOS fix? If so, is macOS 26.5 expected to prevent the Crashpad handler failure, or is a Codex app update also required? I have not attached dump files because they may contain process memory, local paths, or other private data. I can provide sanitized counts, timestamps, or logs if that would help diagnose it. lske837 commented on Sep 1, 2026 lske837 on Sep 1, 2026 More actions I am seeing what appears to be the same class of issue on macOS, although my Crashpad database path is different: ~/Library/Application Support/Codex/Crashpad/pending My Codex Desktop version is 26.825.51511. The live Codex helper processes use: --user-data-dir=/Users/xxx/Library/Application Support/Codex --database=/Users/xxx/Library/Application Support/Codex/Crashpad The pending directory contains the same paired .dmp and _sidecar.json files described in this issue. Some sampled reports date back to June 2026, while others are from late August. The directory has become so large that even enumerating it is very slow: a bounded directory read did not finish within 8 seconds. A bounded scan managed to process only 118 entries (about 10 MB) before timing out, so this is not a normal small crash-report queue. It also appears to still be active rather than merely containing old leftovers: the pending directory modification time advanced from 2026-09-01 15:51:03 +0800 to 2026-09-01 15:51:34 +0800 during a 30-second read-only observation. Separately, when this happens I have also observed a process named ReportClash continuously consuming CPU. I do not yet know whether it is a Codex child/helper process or an unrelated process, so I am reporting it as a correlation only. lske837 commented on Sep 1, 2026 I am seeing what appears to be the same class of issue on macOS, although my Crashpad database path is different: ~/Library/Application Support/Codex/Crashpad/pending My Codex Desktop version is 26.825.51511. The live Codex helper processes use: --user-data-dir=/Users/xxx/Library/Application Support/Codex --database=/Users/xxx/Library/Application Support/Codex/Crashpad The pending directory contains the same paired .dmp and _sidecar.json files described in this issue. Some sampled reports date back to June 2026, while others are from late August. The directory has become so large that even enumerating it is very slow: a bounded directory read did not finish within 8 seconds. A bounded scan managed to process only 118 entries (about 10 MB) before timing out, so this is not a normal small crash-report queue. It also appears to still be active rather than merely containing old leftovers: the pending directory modification time advanced from 2026-09-01 15:51:03 +0800 to 2026-09-01 15:51:34 +0800 during a 30-second read-only observation. Separately, when this happens I have also observed a process named ReportClash continuously consuming CPU. I do not yet know whether it is a Codex child/helper process or an unrelated process, so I am reporting it as a correlation only. dewalt-1 commented on Sep 2, 2026 dewalt-1 on Sep 2, 2026 More actions Still present on the current buildת adding a data point with different characteristics from the browser_crashpad_handler SIGTRAP loop in #36982. Environment: ChatGPT.app 26.818.41509 (build 6962), bundle com.openai.codex, Codex Framework (Chromium) 151.0.7922.170, macOS 15.6.1. ~/Library/Application Support/Codex/Crashpad/pending is 174.6 GB, against 171 MB for everything else in Application Support/Codex combined — 99.9% of the directory. Uniform ~161 KB .dmp + _sidecar.json pairs ({"capture_kind":"crash"}), so ≈1.08M dumps and >2M files. The directory's link count has saturated at 65535 and the directory entry itself is 65 MB. Differences from #36982: No browser_crashpad_handler-*.ips in ~/Library/Logs/DiagnosticReports (30 reports present, none from the handler). Not in a tight loop: last write to pending/ was 16 hours ago and the app has run since without adding to it. Dump annotations reference Utility and extension process types. Crashpad/ was created 2026-04-05, so ~1.1 GB/day averaged rather than 5–17 GB/day. Whatever generates the dumps, nothing prunes them. The retention bug looks separable from any specific crash loop: even a low crash rate reaches 175 GB given five months. A size or age cap on pending/ would bound the damage independently of fixing the crashers. dewalt-1 commented on Sep 2, 2026 Still present on the current buildת adding a data point with different characteristics from the browser_crashpad_handler SIGTRAP loop in #36982. Environment: ChatGPT.app 26.818.41509 (build 6962), bundle com.openai.codex, Codex Framework (Chromium) 151.0.7922.170, macOS 15.6.1. ~/Library/Application Support/Codex/Crashpad/pending is 174.6 GB, against 171 MB for everything else in Application Support/Codex combined — 99.9% of the directory. Uniform ~161 KB .dmp + _sidecar.json pairs ({"capture_kind":"crash"}), so ≈1.08M dumps and >2M files. The directory's link count has saturated at 65535 and the directory entry itself is 65 MB. Differences from #36982: No browser_crashpad_handler-*.ips in ~/Library/Logs/DiagnosticReports (30 reports present, none from the handler). Not in a tight loop: last write to pending/ was 16 hours ago and the app has run since without adding to it. Dump annotations reference Utility and extension process types. Crashpad/ was created 2026-04-05, so ~1.1 GB/day averaged rather than 5–17 GB/day. Whatever generates the dumps, nothing prunes them. The retention bug looks separable from any specific crash loop: even a low crash rate reaches 175 GB given five months. A size or age cap on pending/ would bound the damage independently of fixing the crashers. ReymondAkpanya commented on Sep 21, 2026 ReymondAkpanya on Sep 21, 2026 More actions Still present on a much newer build, and I think I can supply the missing piece: why the loop sustains itself. Environment Codex/ChatGPT.app 26.831.21537, Codex Framework (Chromium) 152.0.7977.64 macOS Tahoe 26.3.1 (25D771280a), Apple Silicon The dumps are of the crash handler itself Every .dmp in Crashpad/pending is a minidump of browser_crashpad_handler, not of the app or a renderer. Each one contains the same fatal error: [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) with annotations: executable_path=/Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/152.0.7977.64/Helpers/browser_crashpad_handler --monitor-self-annotation=ptype=crashpad-handler ptype=crashpad-handler Because the handler is launched with --monitor-self-annotation, it monitors itself. So the sequence is: handler calls mach_port_request_notification, gets KERN_INVALID_CAPABILITY (20) hits the CHECK at exception_handler_server.cc:76 and dies the self-monitor writes a minidump of the handler the handler is relaunched, fails the identical check, goto 2 That's a loop with no base case, which is why the growth is perfectly linear rather than correlated with any app activity. Measured rate Exactly 1 dump per second, 181,552 bytes each, plus a 24-byte _sidecar.json: ~3,600 dumps/hour ≈ 0.6 GB/hour ≈ 15 GB/day while the app is running In my case it reached 240,966 files / 21 GB, and took a 228 GB disk down to 0 bytes free — to the point that unrelated tooling could no longer create files. completed/ was empty across all 240,966 reports, so nothing ever drains: uploads never succeed, and there is no cap or TTL on pending/. macOS independently logged 387 .ips reports for the same helper under ~/Library/Logs/DiagnosticReports, oldest dated a week before I noticed anything. There is no user-visible signal at all until the disk fills. The trigger is upstream, the amplification is not The mach_port_request_notification / KERN_INVALID_CAPABILITY failure is not specific to this app — the identical error on Tahoe 26.3.1 is reported against other Chromium/Electron apps: Claude Desktop crashes on macOS Tahoe 26.3.1 — Crashpad mach_port_request_notification failure anthropics/claude-code#37230 Integrated terminal on macOS freezes permanently after running a program that segfaults — Crashpad fatal error kills PTY host microsoft/vscode#282433 So the CHECK failure itself is a Crashpad/Tahoe Mach IPC problem. But the unbounded disk consumption is independent of it: any repeatable handler-startup failure produces the same runaway, because the self-monitor treats the handler's own fatal CHECK as a reportable crash. Two independent mitigations Don't let the self-monitor report the handler's own startup CHECK failure — or back off / rate-limit after N consecutive identical dumps. This alone breaks the loop regardless of the upstream cause. Bound pending/ with a size cap or TTL so a silently failing upload path cannot fill the disk. Either one would have turned this from "disk at 0 bytes" into a log line. Workaround Emptying pending/ and then removing write permission from the directory stops the disk growth immediately (the handler keeps retrying, but can no longer write): P=~/Library/"Application Support"/Codex/Crashpad/pending find "$P" -type f -delete chmod 500 "$P" Confirmed: growth stops, and nothing spills into new/, completed/, or attachments/ — the whole Crashpad directory stays at 20K. Reverse with chmod 700. 👍React with 👍1Reacted by Glenn 'devalias' Grant ReymondAkpanya commented on Sep 21, 2026 Still present on a much newer build, and I think I can supply the missing piece: why the loop sustains itself. Environment Codex/ChatGPT.app 26.831.21537, Codex Framework (Chromium) 152.0.7977.64 macOS Tahoe 26.3.1 (25D771280a), Apple Silicon The dumps are of the crash handler itself Every .dmp in Crashpad/pending is a minidump of browser_crashpad_handler, not of the app or a renderer. Each one contains the same fatal error: [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) with annotations: executable_path=/Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/152.0.7977.64/Helpers/browser_crashpad_handler --monitor-self-annotation=ptype=crashpad-handler ptype=crashpad-handler Because the handler is launched with --monitor-self-annotation, it monitors itself. So the sequence is: handler calls mach_port_request_notification, gets KERN_INVALID_CAPABILITY (20) hits the CHECK at exception_handler_server.cc:76 and dies the self-monitor writes a minidump of the handler the handler is relaunched, fails the identical check, goto 2 That's a loop with no base case, which is why the growth is perfectly linear rather than correlated with any app activity. Measured rate Exactly 1 dump per second, 181,552 bytes each, plus a 24-byte _sidecar.json: ~3,600 dumps/hour ≈ 0.6 GB/hour ≈ 15 GB/day while the app is running In my case it reached 240,966 files / 21 GB, and took a 228 GB disk down to 0 bytes free — to the point that unrelated tooling could no longer create files. completed/ was empty across all 240,966 reports, so nothing ever drains: uploads never succeed, and there is no cap or TTL on pending/. macOS independently logged 387 .ips reports for the same helper under ~/Library/Logs/DiagnosticReports, oldest dated a week before I noticed anything. There is no user-visible signal at all until the disk fills. The trigger is upstream, the amplification is not The mach_port_request_notification / KERN_INVALID_CAPABILITY failure is not specific to this app — the identical error on Tahoe 26.3.1 is reported against other Chromium/Electron apps: Claude Desktop crashes on macOS Tahoe 26.3.1 — Crashpad mach_port_request_notification failure anthropics/claude-code#37230 Integrated terminal on macOS freezes permanently after running a program that segfaults — Crashpad fatal error kills PTY host microsoft/vscode#282433 So the CHECK failure itself is a Crashpad/Tahoe Mach IPC problem. But the unbounded disk consumption is independent of it: any repeatable handler-startup failure produces the same runaway, because the self-monitor treats the handler's own fatal CHECK as a reportable crash. Two independent mitigations Don't let the self-monitor report the handler's own startup CHECK failure — or back off / rate-limit after N consecutive identical dumps. This alone breaks the loop regardless of the upstream cause. Bound pending/ with a size cap or TTL so a silently failing upload path cannot fill the disk. Either one would have turned this from "disk at 0 bytes" into a log line. Workaround Emptying pending/ and then removing write permission from the directory stops the disk growth immediately (the handler keeps retrying, but can no longer write): P=~/Library/"Application Support"/Codex/Crashpad/pending find "$P" -type f -delete chmod 500 "$P" Confirmed: growth stops, and nothing spills into new/, completed/, or attachments/ — the whole Crashpad directory stays at 20K. Reverse with chmod 700. ashtonsix commented on Oct 5, 2026 ashtonsix on Oct 5, 2026 More actions Adding a measured data point from 2026-10-05 on macOS 26.0.1 (25A362), arm64. ~/Library/Application Support/Codex/Crashpad/pending contained 1,212,428 files removed during cleanup: 110,728,502,872 logical bytes / 114,221,113,344 allocated bytes (114.22 GB). File mtimes ranged from 2026-07-27 through 2026-10-04. The dump-header timestamp histogram included 85,720 dumps on 2026-08-27 alone. This backlog was a major contributor to an almost-full 500 GB disk. I parsed ten retained minidump samples before deleting them. All ten named this main module: /Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/151.0.7922.76/Helpers/browser_crashpad_handler Each sampled dump was 182,624 bytes and identified ARM64. This corroborates reports here that the crash handler itself is being dumped, although the sample does not establish that every report had the same cause. The currently installed app is 26.930.21537 (build 12776), with framework 154.0.8037.93. The pending queue has stayed empty during today's cleanup while the app remains usable. I am reporting a historical backlog, not claiming that the current build is actively reproducing the loop or that the underlying bug is fixed. For local containment, I installed a LaunchAgent that runs every five minutes, expires reports older than 24 hours, and additionally caps each pending/completed queue at 64 report groups and 256 MiB. It groups matching UUID dump/sidecar files, gives fresh writes a two-minute grace period, and skips unknown files, symlinks, and files that change during inspection. This bounds retained diagnostic storage without making the database unwritable, but it does not repair a crashing helper. A built-in retention/size limit would prevent this degree of disk exhaustion independently of the handler failure. No raw minidumps are attached. ashtonsix commented on Oct 5, 2026 Adding a measured data point from 2026-10-05 on macOS 26.0.1 (25A362), arm64. ~/Library/Application Support/Codex/Crashpad/pending contained 1,212,428 files removed during cleanup: 110,728,502,872 logical bytes / 114,221,113,344 allocated bytes (114.22 GB). File mtimes ranged from 2026-07-27 through 2026-10-04. The dump-header timestamp histogram included 85,720 dumps on 2026-08-27 alone. This backlog was a major contributor to an almost-full 500 GB disk. I parsed ten retained minidump samples before deleting them. All ten named this main module: /Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/151.0.7922.76/Helpers/browser_crashpad_handler Each sampled dump was 182,624 bytes and identified ARM64. This corroborates reports here that the crash handler itself is being dumped, although the sample does not establish that every report had the same cause. The currently installed app is 26.930.21537 (build 12776), with framework 154.0.8037.93. The pending queue has stayed empty during today's cleanup while the app remains usable. I am reporting a historical backlog, not claiming that the current build is actively reproducing the loop or that the underlying bug is fixed. For local containment, I installed a LaunchAgent that runs every five minutes, expires reports older than 24 hours, and additionally caps each pending/completed queue at 64 report groups and 256 MiB. It groups matching UUID dump/sidecar files, gives fresh writes a two-minute grace period, and skips unknown files, symlinks, and files that change during inspection. This bounds retained diagnostic storage without making the database unwritable, but it does not repair a crashing helper. A built-in retention/size limit would prevent this degree of disk exhaustion independently of the handler failure. No raw minidumps are attached. ahmedkhan25 commented on Oct 17, 2026 ahmedkhan25 on Oct 17, 2026 More actions Still happening on the current build, and at a much larger scale. Measured 2026-10-15 to 2026-10-17: Environment ChatGPT.app 26.1007.71326 (build 20398), Codex Framework (Chromium) 155.0.8059.40 macOS 15.7.4, Apple Silicon (arm64) What I found Folder Size Files ~/Library/Application Support/com.openai.codex/web/Crashpad 180 GB 2,251,765 ~/Library/Application Support/Codex/Crashpad (almost all of it in pending/) 143 GB 1,785,095 Total ~323 GB ~4.04 million That was about 35% of a 926 GB disk. Free space fell to 1.4 GB before I found it. Nothing in the app warned me. I only found it by running du over ~/Library. The app kept working the whole time, as others have reported here. So the dumps build up silently in the background with no limit. Cleanup With the app still running, I renamed both Crashpad folders and deleted the renamed copies. Free space went from 1.4 GB to 50+ GB within minutes, and the delete is still running (millions of small files). Asks Put a size or count cap on Crashpad/pending, with automatic pruning (see also Add storage limits and automatic cleanup for Codex-generated data #51361). Stop the handler crash loop that produces the dumps ( [app][macOS][26.727.51351] browser_crashpad_handler SIGTRAPs 2ms after launch, launchd respawns it, Crashpad/pending fills disk at ~17GB/day #36982). Show a warning in the app when its own data goes over a few GB. Related: #36982, #39875, #51739, #52194, #51361. ahmedkhan25 commented on Oct 17, 2026 Still happening on the current build, and at a much larger scale. Measured 2026-10-15 to 2026-10-17: Environment ChatGPT.app 26.1007.71326 (build 20398), Codex Framework (Chromium) 155.0.8059.40 macOS 15.7.4, Apple Silicon (arm64) What I found That was about 35% of a 926 GB disk. Free space fell to 1.4 GB before I found it. Nothing in the app warned me. I only found it by running du over ~/Library. The app kept working the whole time, as others have reported here. So the dumps build up silently in the background with no limit. Cleanup With the app still running, I renamed both Crashpad folders and deleted the renamed copies. Free space went from 1.4 GB to 50+ GB within minutes, and the delete is still running (millions of small files). Asks Put a size or count cap on Crashpad/pending, with automatic pruning (see also Add storage limits and automatic cleanup for Codex-generated data #51361). Stop the handler crash loop that produces the dumps ( [app][macOS][26.727.51351] browser_crashpad_handler SIGTRAPs 2ms after launch, launchd respawns it, Crashpad/pending fills disk at ~17GB/day #36982). Show a warning in the app when its own data goes over a few GB. Related: #36982, #39875, #51739, #52194, #51361. Metadata Metadata Assignees Labels Type Projects Milestone Relationships Development Issue actions Open in GitHub Copilot app