Codex Desktop 26.908.40834 (Windows): composer never submits after app restart; "invalid transport in mcp_servers.codex_app"

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

26.908.40834 (MSIX package OpenAI.Codex 26.908.4834.0), bundled app-server codex-cli 0.154.0-alpha.6.2

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

Since the self-update to 26.908.40834 on 2026-09-12 12:09 (Europe/Amsterdam; previous build 26.903.71938 was fine) the desktop app is effectively unusable for existing chats and, since 2026-09-13, also for new chats. Three related symptoms:

1. Thread start/resume fails with an MCP config error
failed to load configuration: invalid transport in mcp_servers.codex_app (JSON-RPC -32600, failureReason=invalid_config). 177 occurrences in the desktop logs on 2026-09-12, 0 on any earlier day. The user's config.toml contains no mcp_servers.codex_app at all.

2. After an app restart, a resumed chat never submits a new message
No turn/start is ever sent by the renderer; the send button stays in its loading state. The main process logs Conversation state not found conversationId=<resumed thread> right after thread/resume returned errorCode=null. Since the update, all 20 successful turn/start calls were in threads created in the same app session; 0 in resumed threads. With 26.903 resumed threads accepted messages normally.

3. Since 2026-09-13 even a new chat in a project does not submit
model/list and experimentalFeature/list are requested when the composer opens, but no thread/start follows when pressing Enter or the send button. The app-server (codex.exe) is idle and healthy; codex exec from the CLI with the same config completes a turn in 9 s.

Warnings that appear in every affected session and never before 26.908: Received broadcast but no handler is configured method=thread-stream-following-status-requested (also thread-stream-following-changed, client-status-changed, query-cache-invalidate). Occasionally mcp_request_timeout method=plugin/installed (30 s) and, in the app-server log, MCP server startup failed server_name="codex_app" error=timed out awaiting tools/list after 10s, but sessions without these also fail to submit.

What steps can reproduce the bug?

Symptom 1 (invalid transport)

1. Codex Desktop 26.908.40834 on Windows, app-server 0.154.0-alpha.6.2, any config.toml without a [mcp_servers.codex_app] block.
2. Start the app, open an existing chat or start a new one from the main window.
3. In some app sessions every thread/start / thread/resume fails with the error above; in other sessions it works. Looks timing-dependent.

CLI reproduction of the underlying rejection:
codex.exe -c "mcp_servers.codex_app.enabled_tools=[\"read_thread\"]" mcp list -> invalid transport in mcp_servers.codex_app. Any override set that includes a command loads fine.

From app.asar: with pluginMcpConfigOverrides (app-server >= 0.151.0-alpha.1) the app sends plugins.codex-app-tools@openai-bundled.mcp_servers.codex_app.enabled=true and no server definition, but in some sessions the main window still sends the legacy key mcp_servers.codex_app.enabled_tools. That creates a top-level mcp_servers.codex_app table without command, which the CLI rejects.

Workaround that removed symptom 1 completely: a top-level [mcp_servers.codex_app] block in config.toml mirroring plugins/cache/openai-bundled/codex-app-tools/0.1.4/.mcp.json (cmd.exe + launch_codex_app_tools_mcp.cmd + server.mjs, cwd = the runtime marketplace copy). After that: thread/start OK, codex_app MCP status ready, 0 further occurrences.

Symptom 2/3 (composer never submits)

1. Have a chat that was created in an earlier app session (any size; also reproduced with a 38M-token / 7 MB rollout thread with history_mode=paginated).
2. Quit and restart the app, open the chat. thread/resume succeeds, then Conversation state not found is logged twice for that conversation.
3. Type a message, press Enter or click send: nothing is sent, no request reaches the app-server.
4. Since 2026-09-13 the same happens for a brand-new chat in a project.

Side effect worth noting: when the app is quit/killed while a turn is running, thread_turns.status stays inProgress in thread_history_1.sqlite; on the next start the chat is shown as still running, cannot be used, and forking is refused ("Forking is not available for threads using paginated history yet"). We found 13 such turns from 2026-08-24 onwards and repaired them manually by appending a turn_aborted event and setting the status to interrupted.

What is the expected behavior?

Existing and new chats accept messages after an app restart, like in 26.903.71938. A turn that is interrupted by quitting the app should be marked interrupted, not left inProgress.

Additional information

Related: #40860 reported the same invalid transport in mcp_servers.codex_app error on macOS with 26.820 and was closed on 2026-08-28 as fixed by a newer build. This report is a regression of that symptom on Windows in 26.908.40834, plus the new composer-never-submits behaviour, which is not covered there.

Logs available: %LOCALAPPDATA%\Codex\Logs\2026\09\12 and ...\13 (desktop), %USERPROFILE%\.codex\logs_2.sqlite (app-server). Happy to share via the in-app "Report an issue" or on request. Locale nl-NL, ChatGPT auth (no API key), no proxy, Microsoft Defender only.

Start with the desktop logs and app-server logs for the reported thread/resume, thread/start, and turn/start sequences. Compare the pluginMcpConfigOverrides and legacy mcp_servers.codex_app paths, then trace the Conversation state not found and inProgress turn behavior after restart. Done means resumed and new project chats submit messages and interrupted turns are marked interrupted without the invalid transport failure.