Windows: silent crash loop (4x in 15 min) leaks orphaned sandbox processes; unbounded 2.48 GB rollout store; `chatgpt://` re-login dead-ends with no fallback

Filed by a business user (Japan) who runs Codex as core operational infrastructure. Codex crashed 4 times within 15 minutes today and then left me unable to log back in at all. Nine distinct, separately-measured defects are documented below with hard numbers. I am asking for each of them to be addressed, not triaged into one vague "stability" bucket.

What version of Codex CLI is running?

0.146.0-alpha.3.1

What subscription do you have?

Pro

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 Home, build 26200, 16 GB RAM)

What terminal emulator and version are you using (if applicable)?

Primary usage is the Codex VS Code extension (rollout DB sources: vscode=851), plus CLI invocations from PowerShell / cmd.exe. No multiplexer.

Codex doctor report

{
  "schemaVersion": 1,
  "overallStatus": "warning",
  "codexVersion": "0.146.0-alpha.3.1",
  "checks": {
    "runtime.search": {
      "status": "warning",
      "summary": "search command could not be verified",
      "details": {
        "search command": "rg.exe",
        "search command readiness": "program not found",
        "search provider": "system"
      },
      "remediation": "Install ripgrep or repair the bundled Codex package."
    },
    "state.paths": {
      "status": "ok",
      "summary": "state paths and databases are inspectable",
      "details": {
        "active rollout files": "1569 files, 2482525975 total bytes, 1582234 average bytes",
        "archived rollout files": "5 files, 19887084 total bytes, 3977416 average bytes",
        "log DB": "C:\\Users\\<user>\\.codex\\logs_2.sqlite (file)",
        "log DB integrity": "ok",
        "state DB": "C:\\Users\\<user>\\.codex\\state_5.sqlite (file)",
        "state DB integrity": "ok",
        "thread history DB": "C:\\Users\\<user>\\.codex\\thread_history_1.sqlite (missing)"
      },
      "durationMs": 60670
    },
    "state.rollout_db_parity": {
      "status": "ok",
      "details": {
        "rollout DB active files": "1569",
        "rollout DB active rows": "1569",
        "rollout DB rows": "1574",
        "rollout DB sources": "vscode=851, subagent:other=518, subagent:thread_spawn=191, exec=14",
        "rollout DB stale rows": "0"
      },
      "durationMs": 69534
    },
    "auth.credentials": {
      "status": "ok",
      "summary": "auth is configured",
      "details": {
        "auth env vars present": "OPENAI_API_KEY",
        "auth storage mode": "File",
        "stored ChatGPT tokens": "true",
        "stored auth mode": "chatgpt"
      }
    },
    "runtime.provenance": {
      "status": "ok",
      "summary": "running local build on windows-x86_64",
      "details": {
        "commit": "unknown",
        "install method": "other",
        "platform": "windows-x86_64",
        "version": "0.146.0-alpha.3.1"
      }
    },
    "installation": {
      "status": "ok",
      "details": {
        "PATH codex #1": "C:\\Users\\<user>\\AppData\\Roaming\\npm\\codex.cmd",
        "current executable": "C:\\Users\\<user>\\AppData\\Local\\OpenAI\\Codex\\bin\\69066b736e1e17a4\\codex.exe",
        "install context": "other",
        "managed by npm": "false"
      }
    },
    "config.load": {
      "status": "ok",
      "details": {
        "feature flags enabled": "38",
        "feature flag overrides": "memories=true",
        "mcp servers": "2",
        "model": "gpt-5.6-sol"
      }
    },
    "sandbox.helpers": {
      "status": "ok",
      "details": {
        "approval policy": "OnRequest",
        "filesystem sandbox": "restricted",
        "network sandbox": "restricted"
      }
    },
    "system.environment": {
      "status": "ok",
      "details": {
        "os": "Windows 10.0.26200 (Windows 11 Core) [64-bit]",
        "os language": "ja-JP"
      }
    },
    "updates.status": {
      "status": "ok",
      "details": {
        "latest version": "0.145.0",
        "latest version status": "current version is not older"
      }
    }
  }
}

(Full report available on request. Local paths and project names redacted; no secrets were present.)

What issue are you seeing?

Nine separately-verified defects. Every number below is measured on my machine today (2026-07-28), not estimated.

---

1. The main process crashes repeatedly, silently, with no error and no crash report

Reconstructed from the start times of the child processes each crash left behind:

| Crash | Time | Interval |
|---|---|---|
| 1 | 15:22:25 | — |
| 2 | 15:24:54 | +2m29s |
| 3 | 15:35:57 | +11m03s |
| 4 | 15:37:46 | +1m49s |

Four crashes in ~15 minutes, the shortest gap being 1 minute 49 seconds. No dialog, no stack trace, no crash report, nothing written that tells the user what happened. From the user's seat the process simply vanishes mid-work.

2. Crashes leak the sandbox process tree — children are never reaped

Every crash orphans its codex-command-runner process and that runner's node.exe child. Both keep running with a dead parent. Current live orphans:

| PID | Process | Parent PID (dead) | Working set |
|---|---|---|---|
| 24952 | codex-command-runner-0.146.0-alpha.3.1.exe | 26680 | 10.2 MB |
| 24668 | codex-command-runner-0.146.0-alpha.3.1.exe | 14724 | 10.1 MB |
| 21484 | codex-command-runner-0.146.0-alpha.3.1.exe | 31332 | 10.5 MB |
| 7008 | codex-command-runner-0.146.0-alpha.3.1.exe | 8132 | 10.4 MB |
| 1976 / 4816 / 17688 / 23588 | node.exe (children of the above) | — | 273.3 MB combined |

314.6 MB held by 8 processes that nothing owns and nothing will ever clean up. On Windows this is what a Job Object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE exists to prevent. It is not being used.

3. Defect 2 makes defect 1 self-amplifying

Current physical memory:

• Installed: 15.6 GB
• Free: 1.6 GB (~10%)

Crash → orphans retain memory → less free memory → more likely to crash → more orphans. This is a feedback loop, and it explains why my experience is "it keeps crashing" rather than "it crashed once." The product degrades the environment it needs in order to run.

4. Rollout files grow without bound — 2.48 GB, and they make Codex itself slow

Straight from codex doctor:

active rollout files: 1569 files, 2482525975 total bytes, 1582234 average bytes

1,569 files / 2.48 GB, average 1.58 MB each, with stale rows: 0 — i.e. all of it is considered live. There is no cap, no rotation, no age-based pruning.

The performance consequence is measured in the same report:

• state.paths check: 60,670 ms
• state.rollout_db_parity check: 69,534 ms

Over two minutes just to inspect local state. Whatever code path touches this store during normal operation is paying a cost of this order, on a machine with 1.6 GB free. I consider this the most likely proximate cause of defect 1.

5. The log database grows without bound

| File | Size |
|---|---|
| logs_2.sqlite | 740.9 MB |
| state_5.sqlite | 53.5 MB |
| ~/.codex total | 4.66 GB |
| session_index.jsonl | 850 lines (850 sessions, none pruned) |

No size limit, no rotation, no retention policy. A user who never manually intervenes will grow this forever.

6. Temp working directories are never deleted

%LOCALAPPDATA%\Temp currently holds 127 codex-index-* directories. The oldest is from 2026-07-24 20:18 — four days old. Neither session teardown nor startup performs any reclamation.

7. A 32-bit executable is being launched on 64-bit Windows

Windows Event Log, Application, Event ID 1109, provider Wow64 Emulation Layer — 3 occurrences in the last 7 days:

The program or feature "\??\C:\Users\<user>\AppData\Local\Temp\codex-cli-test.exe"
cannot start or run due to incompatibility with 64-bit versions of Windows.
Please contact the software vendor to ask if a 64-bit Windows compatible version
is available.

Codex extracts a 32-bit codex-cli-test.exe into Temp and tries to execute it on a 64-bit OS, where it cannot run. runtime.provenance reports platform: windows-x86_64, so the wrong architecture is being shipped or selected. Windows explicitly tells the user to contact the vendor, which is what I am doing.

Related, from the same report: runtime.search — rg.exe: program not found, remediation "Install ripgrep or repair the bundled Codex package." Two independent signals that the Windows package is incomplete.

8. Token auto-refresh never runs

~/.codex/auth.json:

• id_token expiry: 2026-07-27 15:49:42 (expired ~24 h before the incident)
• last_refresh: empty — never recorded, not once
• refresh_token: present and unused

A refresh token is stored and the refresh path never executes. Worse: codex doctor reports auth.credentials: status "ok" — "auth is configured" while the token is expired. The diagnostic tool cannot detect the very failure the user is experiencing.

9. Re-login is a hard dead end when the ChatGPT desktop app is absent — the worst of the nine

After expiry, Codex invokes a chatgpt:// deep link to re-authenticate. I do not have the ChatGPT desktop app. Verified on my machine:

• HKCU\SOFTWARE\Classes\chatgpt — not registered
• HKLM\SOFTWARE\Classes\chatgpt — not registered
• ChatGPT Store package / installed program — does not exist

Windows therefore shows:

このアプリを開けません
ChatGPT について詳しくは、ストアで調べてください。
[閉じる] [クリップボードにコピー]

("Can't open this app — look for ChatGPT in the Store.")

…and that is the end of the road. There is no fallback to browser auth. There is no fallback to device-code auth. The dialog does not name any alternative. The user is simply locked out of a product they pay for.

The ChatGPT desktop app is not documented as a requirement of Codex. Yet without it, re-authentication is impossible through the path Codex chooses. I recovered only by finding codex login --device-auth myself — a flag reachable only by reading codex login --help line by line. A normal user is stranded here permanently.

---

What steps can reproduce the bug?

Defect 9 (deterministic, and the one that locks users out):

1. Use a Windows machine with no ChatGPT desktop app installed (verify: Test-Path 'HKCU:\SOFTWARE\Classes\chatgpt' → False).
2. Authenticate Codex with auth_mode: chatgpt.
3. Let the token expire — or force it by ensuring last_refresh is empty and id_token.exp is in the past.
4. Start Codex and let it attempt re-authentication.
5. → Windows このアプリを開けません / Can't open this app dialog. No browser opens. No device code appears. No alternative is offered anywhere.

Defects 1–3 (as observed, on a state store grown to the size documented above):

1. Run Codex through the VS Code extension over a period of weeks without ever manually clearing ~/.codex (1,569 rollout files / 2.48 GB / 740 MB log DB accumulated here).
2. Work normally until free physical memory is around 1–2 GB.
3. → The main process terminates without any message, repeatedly, at intervals as short as 1m49s.
4. Run Get-CimInstance Win32_Process -Filter "Name LIKE '%codex-command-runner%'" and compare each ParentProcessId against live PIDs → every parent is dead; every runner and its node.exe child is still running.

Defect 7:

1. Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Wow64 Emulation Layer'} | Where-Object { $_.Message -match 'codex' }
2. → Event ID 1109 for codex-cli-test.exe, 3 occurrences in 7 days.

What is the expected behavior?

Numbered to match the defects above. I am requesting a response on each, with an indication of whether it will be fixed and roughly when.

1. The main process does not crash. When it does, it writes a crash report and tells the user something happened. Silent disappearance of the user's working session is not acceptable behavior for infrastructure software.
2. Crashes do not leak processes. Put the sandbox process tree in a Windows Job Object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE, so codex-command-runner and its node.exe child die with the parent, always — including on abnormal termination.
3. Startup reclaims orphans from previous crashes instead of letting them stack up across a work day.
4. Rollout files are bounded — a size cap, an age-based retention policy, or automatic pruning. 1,569 files / 2.48 GB with stale rows: 0 is not a defensible steady state. Separately, the state-inspection path must not take 60–70 seconds; that cost is being paid somewhere in normal operation too.
5. Log databases are bounded — rotation and retention for logs_*.sqlite, state_*.sqlite, and session_index.jsonl. 4.66 GB in ~/.codex accumulated silently.
6. Temp directories are cleaned up on session end, with startup reclamation of leftovers. Not 127 directories going back four days.
7. Ship the correct architecture. Do not extract a 32-bit codex-cli-test.exe and execute it on 64-bit Windows. Also fix the incomplete package that leaves rg.exe missing.
8. Token refresh actually runs and records last_refresh. And codex doctor must report an expired token as a problem rather than "ok" — a diagnostic that stays green during the exact failure it should catch is worse than no diagnostic.
9. Authentication always has a working path. If the chatgpt:// deep link cannot be resolved, automatically fall back to browser auth or device-code auth — do not hand the user an OS-level "can't open this app" dialog and stop. At minimum, the failure path must name codex login --device-auth. And please state plainly in the documentation whether the ChatGPT desktop app is a requirement of Codex; if it is not, then this dead end must not exist.

Additional information

These nine items are not nine unrelated bugs. They cluster into four missing pieces of engineering discipline:

• No teardown on abnormal exit (2, 3, 6)
• No bounds on anything that accumulates (4, 5, 6)
• No fallback when the happy path fails (9)
• No verification of what ships or of what diagnostics report (7, 8)

Every one of them is invisible to a user until the day the machine runs out of memory and the product starts dying every two minutes — which is the day I am reporting from.

I understand 0.146.0-alpha.3.1 is a pre-release. That explains rough edges. It does not explain a product that crashes without a message, leaves its own child processes running, grows to 4.66 GB unbounded, ships the wrong CPU architecture, and then locks a paying Pro user out of re-authentication with no fallback whatsoever. Those are not rough edges; they are absent fundamentals, and shipping them behind an alpha tag does not make a halted business day acceptable.

I run my business operations on Codex. That was a deliberate choice made in good faith. When it dies, my work stops, and today I spent it reverse-engineering process trees and registry keys to discover an undocumented CLI flag — work that should not have been mine to do. Please treat defects 2, 4, and 9 as the priorities: the first two are the crash loop, and the third is the one that leaves users with no way back in.