Malformed config.toml can trigger repeated Windows setup loop and desktop input stutter

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

Summary

On Windows, a malformed ~/.codex/config.toml caused the Codex desktop app to repeatedly enter/check Windows setup. Each retry visibly coincided with a short mouse/input stutter. Reinstalling the app did not fix the issue because the malformed user config persisted.

The app became usable again after removing the malformed TOML entry and restarting the desktop app.

Observed error

The desktop app showed an error similar to:

ChatGPT cannot load config.toml, so this conversation cannot continue.
Please fix ...\.codex\config.toml:60:66: unclosed table, expected ']'

The malformed entry was a [projects.'...'] table containing a corrupted/non-ASCII Windows project path whose quoted table key was no longer properly closed.

Behavior

While the malformed config was present:

  1. Codex repeatedly showed Windows setup / Windows settings status messages.
  2. The setup message reappeared periodically.
  3. Each reappearance correlated with a brief mouse/input hitch.
  4. Codex conversations could not proceed normally because config loading failed.
  5. Reinstalling the desktop app did not resolve the problem.

After removing only the malformed project table from config.toml and restarting the app:

  • the config loaded successfully;
  • Codex opened normally;
  • the repeated Windows setup loop stopped;
  • the periodic mouse/typing stutter disappeared.

Relevant config

A valid Windows fallback setting was present elsewhere in the config:

[windows]
sandbox = "unelevated"

However, because the TOML parser failed earlier in the file, this setting appeared not to be applied reliably until the syntax error was fixed.

Environment

  • Windows desktop app
  • Observed package/process path referenced a build similar to OpenAI.Codex_26.803.10989.0_x64
  • config.toml stored under the normal user-level ~/.codex directory

Notes on how the malformed config may have been created

Before the failure, a local automation/script had rewritten Codex configuration values. The exact source of the malformed project entry is not proven, so I would not attribute the corruption to Codex itself without further evidence.

The more actionable issue is the recovery behavior: a single TOML syntax error appears able to put the Windows desktop app into a repeated setup/preflight loop that causes noticeable UI/input stalls.

Suggested improvements

  1. If config.toml fails to parse, stop Windows sandbox/setup retries rather than repeatedly entering setup/preflight.
  2. Surface the config parse error as the primary blocking condition with a clear recovery action.
  3. Consider loading a minimal safe default config when parsing fails, or at least avoid invoking unrelated Windows setup checks.
  4. Consider preserving/repairing malformed project trust entries independently so one bad [projects.*] key does not destabilize the entire desktop startup flow.
  5. If setup/preflight is retried, add backoff and avoid work on the UI/input-sensitive path.

Workaround

  1. Exit Codex/ChatGPT completely.
  2. Back up ~/.codex/config.toml.
  3. Locate and remove/fix the malformed TOML table entry.
  4. Verify the file parses and that the intended [windows] sandbox setting is still present.
  5. Restart the desktop app.

This fully resolved the repeated setup loop and input stutter in the observed case.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 14 days ago

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

  • #37740
  • #37616

Powered by Codex Action

satoshinj · 8 days ago

Hit the same malformed [projects.'...'] entry on the CLI side (not the desktop app), and I have before/after copies of the config that may cover the evidence gap you mentioned.

codex refused to start with:

Error loading config.toml:
C:\Users\user\.codex\config.toml:136:46: unclosed table, expected `]`

What the corruption looks like

Comparing a backup from 2026-08-11 with the file as it stood on 2026-08-20, every non-ASCII project key changed and no ASCII key did:

2026-08-11 backup   [projects.'d:\workspace\表格']          <- valid UTF-8, quote closed
2026-08-20 file     [projects.'d:\workspace\琛ㄦ牸']         <- mojibake

The transformation is exact and reversible: the UTF-8 bytes of the path were decoded as GBK (system ANSI codepage, cp936 here) and the result re-encoded as UTF-8. '琛ㄦ牸'.encode('gbk').decode('utf-8') gives back 表格. Same for 临时项目 -> 涓存椂椤圭洰.

Counts in that file: 31 [projects.*] entries, 25 pure-ASCII paths all intact, 6 non-ASCII paths all corrupted.

Two of the six also lost their closing '. Both are longer paths whose final byte pair could not be mapped, so it became a literal ? that consumed the quote:

2026-08-11   [projects.'d:\workspace\<24 Chinese chars>']   parses fine
2026-08-20   [projects.'d:\workspace\鐜搴旀€ラ妗堝鏌?]        unclosed table

That is what makes the file unparseable — the mojibake alone is harmless, the eaten quote is not.

Why this points at the writer, not an external script

  • The 2026-08-11 backup has all 6 non-ASCII keys correct and properly quoted, so they were written correctly at some point.
  • Only non-ASCII keys are affected; the 25 ASCII paths in the same file are byte-identical.
  • The damage is a clean single-pass codepage misread, not arbitrary truncation.

I cannot point at the exact write, so I am reporting the shape of the damage rather than a cause.

Environment

  • codex-cli 0.148.0, Windows 10 Pro 19045, system ANSI codepage 936 (GBK)
  • Project directories under D:\workspace\ with Chinese names
  • Recovery: adding the missing ' back was enough to make codex start again; removing the 6 mojibake entries only costs re-confirming trust for those directories