Codex Desktop به طور مداوم موارد در حال انتظار Crashpad را تولید می کند

## خلاصه

Codex Desktop به طور پیوسته فایل‌های جفت «.dmp» و «_sidecar.json» را در زیر اضافه می‌کند:

``متن ~/Library/Application Support/com.openai.codex/web/Crashpad/pending ```

در دستگاه من، این فهرست در یک روز به فایل‌های «4.9G» و «54504» رسید. این تعداد در طول بررسی افزایش یافت، بنابراین به نظر می‌رسد که تولید زباله‌های Crashpad فعال به جای باقیمانده‌های بیات یک‌باره باشد.

برنامه Codex Desktop در حالی که این اتفاق می افتد هنوز فعال است. من می توانم از برنامه استفاده کنم، سیستم فایل را بررسی کنم و با GitHub از همان جلسه در حال اجرا تعامل داشته باشم.

بنابراین مشکل قابل مشاهده توسط کاربر این نیست که Codex به طور کامل خراب است یا نمی تواند راه اندازی شود. مشکل این است که Crashpad به طور مداوم جفت‌های dump/sidecar معلق در پس‌زمینه تولید می‌کند در حالی که برنامه همچنان قابل استفاده است و باعث رشد نامحدود دیسک محلی می‌شود.

من minidump ها را به صورت عمومی پیوست نمی کنم زیرا ممکن است حاوی حافظه، مسیرهای محلی یا داده های خصوصی باشند. اگر نگهبانان OpenAI یک مسیر آپلود امن ارائه دهند، می‌توانم جدیدترین «.dmp» را به‌صورت خصوصی به اشتراک بگذارم.

## محیط زیست

- محصول: برنامه Codex Desktop در macOS - نسخه برنامه Codex: `26.527.60818` - "CFBundleVersion": "3437". - حاشیه‌نویسی Crashpad/Electron مشاهده شده از فرآیند زنده: «prod=Codex_Mac», «ver=148.0.7778.179». - macOS: `26.3.1 (25D771280a)` - معماری: `arm64`

## شواهد مشاهده شده

دایرکتوری در انتظار کرش پد:

``متن ~/Library/Application Support/com.openai.codex/web/Crashpad/pending ```

آخرین اندازه گیری ها:

``متن 4.9G ~/Library/Application Support/com.openai.codex/web/Crashpad/pending در مجموع 54504 فایل 27252 فایل dmp 27252 فایل _sidecar.json ```

محدوده زمانی فایل در انتظار نمونه:

``متن قدیمی ترین فایل های در حال انتظار نمونه برداری شده: 02-06-2026 13:31:21 CEST آخرین نمونه فایل های در حال انتظار: 2026-06-02 21:08:24 CEST ```

در طول بررسی، تعداد از «53،444» به «54،064» و سپس به «54،504» افزایش یافت، که نشان می‌دهد صف همچنان در حال رشد است.

من همچنین دو فرآیند «browser_crashpad_handler» Codex را مشاهده کردم که تحت «PPID=1» از «شنبه 30 مه 11:47:50 2026» اجرا می‌شدند که هر دو از یک پایگاه داده Crashpad استفاده می‌کردند:

``متن /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 ```

برنامه محلی به اندازه کافی قابل استفاده برای بررسی/گزارش این موضوع باقی مانده است، بنابراین مشکل قابل مشاهده فقط یک خرابی عادی برنامه پیش زمینه نیست. به نظر می‌رسد کرش‌پد یا یک فرآیند کمکی نظارت‌شده به‌طور مکرر و بدون محدود کردن، پاک‌سازی آپلود/پردازش یا چرخش، زباله‌های معلق تولید می‌کند.

## رفتار مورد انتظار

گزارش‌های خرابی باید محدود، آپلود/پردازش/چرخ شوند یا تا زمانی که برنامه قابل استفاده باقی می‌ماند، به‌طور مداوم تولید نشوند.

## رفتار واقعی

گزارش‌های در حال انتظار Crashpad به سرعت جمع می‌شوند و چندین گیگابایت فضای دیسک محلی را مصرف می‌کنند.

## دستورات مورد استفاده برای جمع آوری شواهد

ش du -sh "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending"

پیدا کردن "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f | wc -l

پیدا کردن "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f \ | sed 's/.*\.//' | مرتب کردن | uniq -c | مرتب سازی -شماره

/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 unname -m

ps ax -o pid,ppid,lstart,command \ | grep -E 'browser_crashpad_handler|com.openai.codex/web/Crashpad' \ | grep -v grep ```

## مسائل مرتبط

این ممکن است مربوط به سایر گزارش‌های پاکسازی فرآیند یا کمکی Codex Desktop باشد:

- #25259: کمک کننده Crashpad پس از به روز رسانی/راه اندازی مجدد - #11090: پردازش های Codex یتیم و UI مسدود می شود - #10627: گزارش های قبلی راه اندازی Crashpad/macOS