Windows power loss zero-fills config.toml and hangs desktop + VS Code Codex

Start by tracing the config/read path and the handling of ~/.codex/config.toml, using the reported Windows logs and zero-filled file as the reproduction. Review how malformed configuration is handled by the desktop app and VS Code extension. Done means corrupted shared state no longer leaves either client hanging and recovery produces defaults or an actionable error.

Summary

After an unexpected Windows power loss, ~/.codex/config.toml became a 4,146-byte file containing only 0x00 bytes. Both the Codex Windows desktop app and the Codex VS Code extension then hung indefinitely during startup.

The desktop app, extension, Windows, and machine had all been restarted. Repairing/resetting and reinstalling the app did not resolve the problem because the corrupted shared configuration remained in ~/.codex.

Replacing the corrupted file with an empty, valid config.toml immediately restored both clients.

Environment

• Windows 11, build 26100
• Codex desktop: 26.715.4045.0
• VS Code Codex extension: 26.715.31925-win32-x64
• Shared config path: C:\Users\Administrator\.codex\config.toml
• Official feedback thread: 019f78da-15b2-7a72-a9c4-897fd7a5bcdd

Observed behavior

1. Windows lost power unexpectedly.

2. After reboot, Codex desktop remained on the loading/splash screen indefinitely.

3. The VS Code Codex extension also remained stuck and did not become usable.

4. Restarting processes and Windows, updating, repairing/resetting, and reinstalling did not fix either client.

5. Inspection showed that config.toml was exactly 4,146 bytes long and every byte was 0x00:

   TotalBytes=4146
   ZeroBytes=4146
   NonZeroBytes=0
   FirstNonZeroOffset=-1
   LastNonZeroOffset=-1
   

6. Both desktop and extension logs repeatedly reported configuration-read failures.

Relevant log messages

VS Code extension:

codex_app_server: Invalid configuration; using defaults.
C:\Users\Administrator\.codex\config.toml:1:4147: key with no value, expected `=`

failed to read configuration layers:
C:\Users\Administrator\.codex\config.toml:1:4147: key with no value, expected `=`

Codex desktop repeatedly reported:

Request failed ... method=config/read ...
failed to read configuration layers:
C:\Users\Administrator\.codex\config.toml:1:4147: key with no value, expected `=`

The message says "using defaults", but the clients continued calling config/read and never recovered or displayed an actionable error.

Workaround

Copy-Item "$env:USERPROFILE\.codex\config.toml" `
  "$env:USERPROFILE\.codex\config.toml.corrupt.bak"

[IO.File]::WriteAllText(
  "$env:USERPROFILE\.codex\config.toml",
  '',
  (New-Object Text.UTF8Encoding($false))
)

After restarting Codex and reloading VS Code, both clients worked again.

Expected behavior

• Configuration writes should use a crash-safe atomic replacement strategy and preserve a last-known-good copy.
• A truncated or zero-filled configuration should be detected during startup.
• Codex should quarantine the corrupted file and actually continue with defaults, or show an actionable recovery dialog.
• A malformed shared config should not leave both desktop and IDE surfaces hanging indefinitely.
• Repair/reset/reinstall flows should detect or clearly report corruption in shared ~/.codex state.

Impact

Because desktop and IDE surfaces share ~/.codex/config.toml, a single interrupted write can disable both clients. The current splash-screen symptom gives no indication that the shared configuration is the cause, making common recovery steps ineffective.