[App] Windows setup hangs after invalid TOML written to shell_environment_policy.set

What version of the Codex App are you using (From "About Codex" dialog)?

26.715.21425

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After an app update and reboot, the app gets stuck on the "Finish Windows setup" screen ("ChatGPT necesita un permiso por única vez para funcionar en tu computadora"). The UAC dialog shown there never triggers a real Windows elevation prompt, and clicking "Retry" fails instantly — same symptom already reported in #32149, #32248 and #32492.

<img width="571" height="546" alt="Image" src="https://github.com/user-attachments/assets/87ee3e7f-8aaa-4bba-ab6b-02f117cfc31c" />

Root cause found on my machine: %CODEX_HOME%\config.toml contained invalid TOML. Instead of a normal inline table:

[shell_environment_policy]
set = {}

the file had a malformed, two-line table header with a comment embedded inside the brackets:

[# Explicit key/value overrides (always win). Default: {}
shell_environment_policy.set ]
BROWSER_USE_AVAILABLE_BACKENDS = "chrome"
NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S = "..."
NODE_REPL_TRUSTED_CODE_PATHS = '...'

This is not valid TOML (a [table] header can't span two lines or contain a # before the key path), so config.toml fails to parse, and the app appears to misroute that failure into the "Finish Windows setup" gate instead of showing a config error.

What steps can reproduce the bug?

1. Not fully reproducible on demand — it appears to happen when the app rewrites shell_environment_policy.set in config.toml, likely while persisting a new NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S entry (browser-tool trust update) during/after an app update.
2. After it happens, config.toml contains the malformed table header shown above, and the app hangs on "Finish Windows setup" on every subsequent launch, with "Retry" failing instantly.
3. Workaround: close the app, rename config.toml (e.g. to config.toml.old), relaunch — the app regenerates a fresh, valid config.toml and starts normally.

Note: this isn't a one-off — I keep a version-controlled backup of this file, and the same shell_environment_policy.set corruption pattern shows up across multiple past syncs, meaning this write bug has recurred more than once on this machine.

What is the expected behavior?

config.toml writes should always produce valid TOML. If the file is ever invalid, the app should surface a clear "config.toml failed to parse: <error>" message instead of silently hanging on the Windows sandbox setup screen with a non-functional Retry button.

Additional information

Happy to share a redacted copy of the corrupted config.toml if useful for reproducing the serializer bug. Related: #32149, #32248, #32492.