Desktop: editing automation RRULE crashes mid-write, leaves persistent corrupt state surviving uninstall + reinstall

Open 💬 2 comments Opened May 26, 2026 by NedMalki-Chief
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Editing an automation's repeat interval (RRULE) in the desktop UI crashed the renderer mid-write, leaving corrupt state that persistently crashes the app on every subsequent launch — including after a full uninstall + Microsoft Store reinstall. State corruption is in %USERPROFILE%\.codex\ which is not removed by the MSIX uninstaller.

Environment

  • OS: Windows 11 Pro, version 10.0.26200
  • MSIX package: OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0
  • Bundled app-server: 0.133.0-alpha.1
  • CLI (separate install): codex-cli 0.130.0-alpha.5
  • GPU: NVIDIA GeForce RTX 3080 Laptop GPU + AMD Radeon integrated (Optimus laptop)

Reproduction (initial trigger)

  1. Open Codex desktop, navigate to an existing automation
  2. Open Repeats → Custom RRULE editor (e.g. FREQ=HOURLY;INTERVAL=1)
  3. Manually edit the interval value
  4. Renderer crashes immediately, window closes silently
  5. From this point onward the app cannot be re-launched — every subsequent launch crashes ~1 second after init

Crash signature

Desktop log (%LOCALAPPDATA%\Packages\OpenAI.Codex_<id>\LocalCache\Local\Codex\Logs\<date>\codex-desktop-*.log) ends at the same line every launch:

info Launching app
info [AppServerConnection] Initializing app-server transport
info [StdioConnection] stdio_transport_spawned ... codex.exe ... currentVersion=0.133.0-alpha.1
info [AppServerConnection] initialize_handshake_result outcome=success
info [AppServerConnection] Codex CLI initialized
info [IpcRouter] I am the router
<crash, no further lines>

App-server handshake succeeds. Crash is in the Electron renderer ~700ms after IpcRouter setup — when the renderer presumably reads persisted state, queued follow-ups, and automation metadata.

Crashpad dump created on every crash, ~34.8 MB, MDMP magic. Strings in the dump reference DawnGraphiteCache and Chrome IO thread.

Persistent state surviving uninstall + reinstall

The MSIX uninstall does not remove %USERPROFILE%\.codex\. Corrupt state lives there, so a full reinstall does nothing.

After bisecting, the crash-driving file is %USERPROFILE%\.codex\.codex-global-state.json. With this file fully removed, the app launches cleanly (empty sidebar). Restoring even 5 minimal keys from a backup (electron-main-window-bounds, electron-local-remote-control-installation-id, primary-runtime-update-jitter-ms, use-copilot-auth-if-available, remote-project-connection-backfill-completed) reproduces the crash — so corruption is not isolated to the large electron-persisted-atom-state (221 KB) or queued-follow-ups (211 KB) blobs alone, and may also live in SQLite (~/.codex/sqlite/codex-dev.db) or the automations/ directory.

Workarounds attempted

| Attempt | Result |
|---|---|
| Clear GPU caches (DawnWebGPUCache, DawnGraphiteCache, GPUCache, Cache, Code Cache) | Still crashes |
| ELECTRON_DISABLE_HARDWARE_ACCELERATION=1 in User env | Still crashes |
| Force NVIDIA via Windows Graphics + NVIDIA Control Panel | Still crashes |
| Quarantine large session JSONL files (>50 MB) | Still crashes |
| Bulk-delete old sessions / archived_sessions / worktrees (~3.7 GB freed) | Still crashes |
| Uninstall + reinstall MSIX from Microsoft Store | Still crashes (state survives) |
| Move .codex-global-state.json aside entirely | Opens but sidebar empty |
| Partial restore (11/13 keys, exclude two large blobs) | Crashes |
| Ultra-minimal restore (5 trivial flag keys, no thread/project refs, 0.37 KB) | Crashes |

The fact that even a 370-byte state file with no thread refs and no project refs reproduces the crash suggests corruption is also in another file the renderer reads on startup.

Requests

  1. Recovery tool: ship a codex doctor / codex reset-desktop-state command that safely rebuilds corrupt local state without requiring users to bisect JSON keys.
  2. Atomic writes: write the automation RRULE atomically (write-temp-then-rename) so a crash mid-edit cannot leave half-written state.
  3. Uninstall: have the MSIX uninstaller offer to remove %USERPROFILE%\.codex\ (currently kept, blocking clean reinstall recovery).
  4. Auto-recovery on launch: when the renderer hits this state, quarantine the bad blobs and continue, rather than killing the process.
  5. Crashpad symbols: ship public PDBs (or accept dumps directly) so users can self-diagnose.

Related

  • #21342 — automation RRULE display bug
  • #23814 — Desktop Windows: repeated silent window closes
  • #21750 — state runtime: corrupt state_5.sqlite wedges startup with no auto-recovery
  • #24408 — Desktop crashes on startup with 0xC000001D
  • #23863 — Desktop startup crash due to sqlx migration checksum mismatch

Crashpad dumps

Local crashpad dumps available at:
%LOCALAPPDATA%\Packages\OpenAI.Codex_<package-id>\LocalCache\Roaming\Codex\Crashpad\reports\*.dmp

Multiple copies, ~34.8 MB each, repeatable. Happy to share dumps privately if needed.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23787
  • #23247

Powered by Codex Action

NedMalki-Chief · 3 months ago

Working fix (for anyone hitting this)

After bisecting, the crash is driven by multiple renderer-side state files, not just .codex-global-state.json. Moving only the JSON aside is not enough — the app re-crashes via SQLite + session index references to deleted/dehydrated data.

The full sweep that fixed it on my machine (Windows 11 26200, MSIX 26.519.5221.0, bundled app-server 0.133.0-alpha.1):

# Close Codex first
Get-Process -Name "Codex" -ErrorAction SilentlyContinue | Stop-Process -Force

# Backup folder
$ts = Get-Date -Format "yyyyMMdd-HHmmss"
$backup = "$env:USERPROFILE\.codex\state-sweep-$ts"
New-Item -ItemType Directory -Path $backup -Force | Out-Null

# Move every renderer-side state file aside (NOT auth, NOT config, NOT automations)
$codexRoot = "$env:USERPROFILE\.codex"
$patterns = @(
  "session_index.jsonl",
  "history.jsonl",
  ".codex-global-state.json",
  ".codex-global-state.json.bak",
  "cap_sid",
  "state_5.sqlite*",
  "logs_2.sqlite*",
  "goals_1.sqlite*"
)
foreach ($pat in $patterns) {
  Get-ChildItem $codexRoot -Filter $pat -Force -ErrorAction SilentlyContinue |
    ForEach-Object { Move-Item $_.FullName "$backup\$($_.Name)" -Force }
}

# Also sweep stale atomic-write orphans from prior crashes
Get-ChildItem $codexRoot -Filter "..codex-global-state.json.tmp-*" -Force -ErrorAction SilentlyContinue |
  ForEach-Object { Move-Item $_.FullName "$backup\$($_.Name)" -Force }

Result after relaunch: app opens clean. Automations preserved (they live in ~/.codex/automations/ as separate files). Auth preserved (auth.json, .credentials.json). Plugins preserved. Project trust levels in config.toml preserved.

Lost: chat history (sat in logs_2.sqlite — 5+ GB on my machine; in backup if anyone wants to attempt non-destructive repair via xdifu/codex-repair). Pinned threads, project sidebar entries, queued automation runs — need re-adding via UI.

What this confirms about the underlying bug

  1. Crash mid-write while editing an automation RRULE leaves bad state across at least 4 separate files simultaneously (.codex-global-state.json, session_index.jsonl, state_5.sqlite, plus dangling .tmp atomic-write orphans).
  2. The renderer's startup path reads all of these eagerly and has no try/catch isolation between them — a single bad ref in any of them kills the whole window.
  3. MSIX uninstall does not touch %USERPROFILE%\.codex\, so reinstalling does nothing.

A codex doctor --reset-renderer-state subcommand (or a Settings UI button) that does the above sweep automatically would unblock every user hitting this without needing PowerShell knowledge.