[Windows Desktop] MCP OAuth secrets decryption requests 1 GiB and fatally crashes codex.exe

Codex version

• Codex Desktop: 26.803.10989.0
• Platform: Windows 11 25H2, build 26200, x64
• Bundled CLI observed around the incident: 0.147.0-alpha.1.2

What issue are you seeing?

Codex Desktop's native codex.exe backend terminated while loading encrypted MCP OAuth credentials.

The application reported:

memory allocation of 1073741824 bytes failed
code=3221226505

Windows recorded:

Exception code: 0xc0000409
FAST_FAIL_FATAL_APP_EXIT (exception information: 7)

The Desktop UI/backend later restarted and reconnected, but the active task was interrupted.

Root-cause evidence from the crash dump

I inspected the Windows minidump without publishing its contents. The failing thread shows this call path:

MCP client/tool initialization
  -> read OAuth tokens for server
  -> load MCP OAuth tokens from encrypted storage
  -> decrypt secrets file
  -> age 0.11.x scrypt recipient
  -> RustCrypto scrypt 0.11.x allocation
  -> Rust allocation error handler
  -> Windows fast-fail

The requested allocation size was also present in register R12 as:

0x40000000 = 1,073,741,824 bytes

The encrypted credential file itself was only about 6 KB. Its sanitized age header was:

age-encryption.org/v1
-> scrypt <salt-redacted> 20
--- <mac-redacted>

No OAuth token, passphrase, salt, MAC, username, local project name, or private server name is included in this report.

The allocation size follows exactly from the implementation parameters:

• age uses ScryptParams::new(log_n, 8, 1, 32)
• the file header has log_n = 20
• RustCrypto allocates N * r * 128 bytes for v
• 2^20 * 8 * 128 = 1,073,741,824 bytes

Relevant upstream code:

• https://github.com/str4d/rage/blob/v0.11.1/age/src/primitives.rs
• https://github.com/str4d/rage/blob/v0.11.1/age/src/scrypt.rs
• https://github.com/RustCrypto/password-hashes/blob/scrypt-v0.11.0/scrypt/src/lib.rs

The age implementation benchmarks the machine and picks a work factor targeting roughly one second. On this machine that produced work factor 20, which also implies a temporary 1 GiB contiguous allocation.

Steps that led to the observed failure

1. Use Codex Desktop on Windows with one or more OAuth-authenticated remote MCP servers/apps.
2. Let Codex create its file-backed encrypted OAuth store with an age scrypt work factor of 20.
3. Keep Codex running with normal desktop memory pressure.
4. Trigger MCP/app initialization or refresh that reads the OAuth credential store.
5. The 1 GiB scrypt allocation can fail.
6. Rust's allocation failure path terminates the entire codex.exe backend with 0xc0000409.

The failure is intermittent because it depends on process/system memory and address-space conditions, but the minidump identifies the immediate caller and exact allocation deterministically.

Expected behavior

Failure to decrypt or allocate memory for an optional MCP OAuth credential store should not terminate the entire Codex backend.

Possible remedies:

• Put a conservative memory/work-factor ceiling on programmatically generated credential stores.
• Avoid CPU-only calibration that can choose a work factor requiring 1 GiB on a fast but memory-constrained Windows machine.
• Catch credential-store/decryption failures and disable only the affected MCP connection.
• Use a fallible/bounded allocation path where possible.
• Prefer the native OS credential store when available, or provide a supported migration path for an existing high-cost encrypted file.
• Log the selected work factor and estimated memory requirement without exposing secret material.

Additional diagnostics

Crash time: 2026-08-13 22:20:38 Europe/Istanbul.

Minidump SHA-256:

7899D64DBF35EB77B221D09D3D7A2DF5B4B9BC4A3ECE1EB253CB1F4FAA2ABE70

The dump is not attached publicly because process dumps can contain credentials or other private memory. I can provide additional sanitized stack offsets/disassembly if maintainers request them.

This is separate from the Windows legacy_notify / os error 206 issue: no notify-hook error occurred in this crash path.