Malformed config.toml can trigger repeated Windows setup loop and desktop input stutter
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:
- Codex repeatedly showed Windows setup / Windows settings status messages.
- The setup message reappeared periodically.
- Each reappearance correlated with a brief mouse/input hitch.
- Codex conversations could not proceed normally because config loading failed.
- 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.tomlstored under the normal user-level~/.codexdirectory
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
- If
config.tomlfails to parse, stop Windows sandbox/setup retries rather than repeatedly entering setup/preflight. - Surface the config parse error as the primary blocking condition with a clear recovery action.
- Consider loading a minimal safe default config when parsing fails, or at least avoid invoking unrelated Windows setup checks.
- Consider preserving/repairing malformed project trust entries independently so one bad
[projects.*]key does not destabilize the entire desktop startup flow. - If setup/preflight is retried, add backoff and avoid work on the UI/input-sensitive path.
Workaround
- Exit Codex/ChatGPT completely.
- Back up
~/.codex/config.toml. - Locate and remove/fix the malformed TOML table entry.
- Verify the file parses and that the intended
[windows]sandbox setting is still present. - Restart the desktop app.
This fully resolved the repeated setup loop and input stutter in the observed case.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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.codexrefused to start with: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:
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: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
I cannot point at the exact write, so I am reporting the shape of the damage rather than a cause.
Environment
D:\workspace\with Chinese names'back was enough to makecodexstart again; removing the 6 mojibake entries only costs re-confirming trust for those directories