Codex Desktop (native Windows agent env): every update re-injects node_repl MCP and eagerly initializes the browser/computer-use runtime at thread start, blocking the composer

<!-- TITLE:
Codex Desktop (native Windows agent env): every update re-injects the node_repl MCP and eagerly initializes the browser/computer-use runtime at thread start, blocking the composer even for chats that never use those tools
-->

Summary

On the native Windows agent environment (not WSL), every Codex Desktop update silently re-introduces a heavyweight startup path that makes the composer "spin" for several seconds before I can even click Send — for every new chat, including a plain "hello" that will never touch a browser, plugin, or computer-use.

The only known way to make it fast again is to disable apps, plugins, browser_use, browser_use_external, in_app_browser, computer_use, tool_suggest, skill_mcp_dependency_install and delete the auto-injected [mcp_servers.node_repl] block — i.e. to give up exactly the features I'd like to keep available. And I have to redo this after every update. This is a false binary: fast OR features, never both.

This is filed separately from #27240 / #26149 (which are about the WSL agent environment). I migrated off WSL to native Windows specifically to escape those, and the eager-init / update-churn problem persists on native Windows.

Environment

• Codex App: 26.609.x (Windows)
• Codex CLI (bundled): 0.140.0-alpha.2
• OS: Windows 10 Pro 19045
• Agent environment: native Windows (thread cwds are C:\... / D:\..., no /mnt/)
• Model: gpt-5.5

Two coupled problems

1. Update churn — config is silently re-armed

My explicit apps=false / plugins=false / browser_use=false / computer_use=false are retained across updates. But each update still:

• (a) Re-writes a full [mcp_servers.node_repl] block into ~/.codex/config.toml, even though the features that need it are disabled. The block points at the browser/computer-use node runtime:

```toml
[mcp_servers.node_repl]
command = '...\runtimes\cua_node\...\node_repl.exe'
startup_timeout_sec = 120

[mcp_servers.node_repl.env]
BROWSER_USE_AVAILABLE_BACKENDS = "chrome"
NODE_REPL_INSTRUCTIONS_USE_CASE_CHROME = "Control the Chrome browser ..."
...
```

• (b) Ships newly-introduced feature flags default-on (browser_use_external, tool_suggest, skill_mcp_dependency_install were enabled after an update because they were not yet present in my config).

2. Eager, synchronous init at thread start blocks the composer

On every thread/start, Codex Desktop synchronously spins up the node_repl runtime and runs app / plugin / marketplace / skill enumeration before the input box becomes responsive. Even on a cold "hello" chat the desktop log shows high thread/start durationMs, IAB_LIFECYCLE browser-route capture, thread_title generation, and plugin/marketplace scans. The plugin/marketplace cache under ~/.codex/.tmp is ~105 MB / ~4,900 files on my machine and is walked at startup.

Impact

Either every new chat pays a multi-second startup tax, or I permanently lose browser_use / computer_use. And I must re-clean config after every update. For a tool used dozens of times a day, where each conversation begins with this delay, this is a serious everyday cost — and it's why a lot of Windows users perceive Codex Desktop as "unusably slow."

Proposed fixes (priority order)

1. Lazy / async init. Do not spawn node_repl / the browser runtime, and do not run app/plugin/marketplace enumeration, at thread/start. Initialize them on first actual use of the corresponding tool. The composer must never be blocked by optional-subsystem initialization.
2. Stop persisting [mcp_servers.node_repl] into user config when the related features are disabled; keep it internal/managed rather than written into config.toml.
3. Respect a minimal/fast profile. Feature flags newly introduced by an update should not silently default-on heavyweight background subsystems for a user who has clearly opted into a minimal-background configuration.
4. Keep the high-churn plugin/marketplace cache off the per-thread hot path (and off /mnt for WSL users — see #26149).

Related

#27240, #26149, #23277, #25715, #24260