Codex app writes invalid transport into mcp_servers.codex_app, blocking all threads after restart

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

26.915.3509.0

What subscription do you have?

Pro and Business

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

Summary

After restarting my computer, the Codex app fails to load its config and no thread will open. The error banner reads:

ChatGPT can't load config.toml, so this thread can't resume.
Fix config.toml: invalid transport in mcp_servers.codex_app.
After saving the file, reopen the thread.

Codex desktop app: 26.915.3509.0
Bundled Codex runtime: 0.155.0-alpha.9
Separately installed CLI: 0.144.6

I never edited config.toml by hand, so the app appears to be writing an invalid transport value into the mcp_servers.codex_app entry itself.

Steps to reproduce

1. Use the Codex app normally.
2. Restart the computer.
3. Open the app.
4. The error banner appears on every thread.

Expected

The app starts with a valid config and threads resume.

Actual

• Existing threads refuse to resume.
• New threads cannot be started — pasting into a new chat does nothing.
• The app is unusable until config.toml is repaired by hand.
• It recurs on every restart, even after a manual fix.

Additional context

In-app feedback was submitted and returned this ID:

no-active-thread-01a0b370-1384-7452-9437-68a93d935235

The no-active-thread- prefix suggests the app could not attach the report to any thread, which is consistent with the failure above.

What steps can reproduce the bug?

1. Use the Codex app normally with the default config at
   C:\Users\<user>\.codex\config.toml (not hand-edited).
2. Restart Windows.
3. Open the Codex app.
4. Open any existing thread, or try to start a new one.

Every thread now shows this banner instead of loading:

ChatGPT can't load config.toml, so this thread can't resume.
Fix config.toml: invalid transport in mcp_servers.codex_app.
After saving the file, reopen the thread.

New threads are affected too — pasting text into a new chat does nothing,
so there is no way to work around it inside the app.

I did not edit config.toml manually, so the invalid transport value in
the mcp_servers.codex_app entry appears to be written by the app itself.

Submitting in-app feedback returned the ID:

no-active-thread-01a0b370-1384-7452-9437-68a93d935235

The no-active-thread- prefix suggests the app could not attach the report
to any thread, consistent with the failure above.

What is the expected behavior?

The app should start normally after a restart and load its config without error.

Specifically:

1. The app should never write a transport value into mcp_servers.codex_app
   that it will then reject as invalid on the next launch.
2. If a config entry really is invalid, the failure should be contained to that
   one MCP server — the app should disable it, warn, and keep working.
3. A broken config for one MCP server should not block unrelated functionality.
   Existing threads should still resume, and it should always be possible to
   start a new thread and type or paste into it.
4. The error message should say what the invalid value is and what the valid
   values are, so the user can actually fix the file.

Additional information

Impact: this is a full block, not a degradation. The app is unusable from
the moment it opens until config.toml is repaired by hand, and it returns on
every restart. There is no in-app workaround, because starting a new thread
fails the same way.

Frequency: reproduces on every restart of Windows.

In-app feedback ID: no-active-thread-01a0b370-1384-7452-9437-68a93d935235
(the no-active-thread- prefix indicates the report could not be attached to
any thread, which is itself a symptom of this bug)

Note on the config file: I have not edited config.toml manually, so the
invalid transport value under mcp_servers.codex_app appears to be written
by the app. If this is a migration or format change between versions, older
configs may need to be upgraded rather than rejected.

Happy to provide the relevant section of config.toml, app logs, or to test
a fix build.

Start by reproducing the restart failure with the default config.toml at C:\Users<user>.codex\config.toml and inspect the mcp_servers.codex_app entry and its transport value. Trace the config load and write paths, then verify that a valid config survives restart and that an invalid MCP entry does not block unrelated threads or new chats.