Desktop app recreates stdio MCP sessions whenever the window regains focus on Windows

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

26.305.950.0

What subscription do you have?

no

What platform is your computer?

_No response_

What issue are you seeing?

What version of Codex is running?

• Codex desktop app package: 26.305.950.0
• MCP client version seen in logs during initialize: 0.110.0

What platform is your computer?

• Windows 10 Pro x64
• OS build: 26200

What model / subscription are you using?

• Not model-specific.
• The issue reproduces before any actual model/tool call.
• If the form requires it, fill in your real subscription tier.

What happened?

Whenever the Codex desktop app loses focus and then regains focus, all configured stdio-based MCP servers are relaunched.

This is visible even when no tool is being called. On every refocus, Codex appears to recreate the MCP client session and rerun the MCP handshake (initialize -> tools/list -> resources/list/resources/templates/list), which causes all stdio MCP child processes to be started again.

What did you expect to happen?

Changing window focus should not recreate all MCP sessions unless:

• the app restarts,
• the MCP config changes, or
• an MCP server actually crashes / disconnects unexpectedly.

How can we reproduce the issue?

1. Configure several local stdio MCP servers in Codex.
2. Launch the Codex desktop app on Windows.
3. Keep Codex open and idle.
4. Click to another application so Codex loses focus.
5. Click back into Codex.
6. Observe that MCP child processes are started again and a fresh MCP handshake happens.

What MCP servers are configured?

The setup includes multiple stdio MCP servers, for example:

• serena
• context7
• sequential-thinking
• chrome-devtools
• copilot-proxy

Evidence

I checked local logs and process trees. The behavior looks like a client-side MCP lifecycle refresh on window refocus rather than an MCP server self-restart.

Key observations:

• Repeated MCP startup and handshake with no actual tool call:
• startup pid=...
• method=initialize
• method=tools/list
• method=resources/list
• method=resources/templates/list
• Wrapper logs show normal exit (exit code=0), so this does not look like a crash/restart loop.
• Multiple MCP servers are relaunched together, not just one custom server.

Why this looks like a Codex app lifecycle issue

The affected MCP wrapper script does not contain restart logic; it only launches the server once and logs the exit code. The MCP server itself also does not contain a retry loop. This suggests the desktop app is recreating the stdio transport/session when the window regains focus.

Impact

• Extra process churn on every app refocus
• Noticeable delay when returning to the app
• More severe when multiple MCP servers are configured
• Makes local MCP tooling feel unstable even though the servers are exiting normally

Logs / local references

Relevant local evidence from this machine:

• MCP config entries:
• C:\Users\14427\.codex\config.toml:29
• C:\Users\14427\.codex\config.toml:84
• MCP wrapper without restart loop:
• C:\Users\14427\.codex\bin\codex-copilot-proxy-mcp.cmd:41
• MCP server handling handshake methods only:
• C:\Users\14427\.codex\mcp-servers\copilot-proxy\server.mjs:516
• C:\Users\14427\.codex\mcp-servers\copilot-proxy\server.mjs:553
• C:\Users\14427\.codex\mcp-servers\copilot-proxy\server.mjs:569
• Repeated handshake log:
• C:\Users\14427\.codex\log\copilot-proxy-parser.log:1348
• Normal exit after relaunch:
• C:\Users\14427\.codex\log\copilot-proxy-start.log:944
• Other MCP servers also relaunched:
• C:\Users\14427\.codex\log\codex-tui.log:45703

Additional note

This may be a desktop-app regression or an intentional refocus refresh policy that is too aggressive for stdio MCP servers on Windows.

What steps can reproduce the bug?

1. Configure several local stdio MCP servers in Codex.
2. Launch the Codex desktop app on Windows.
3. Keep Codex open and idle.
4. Click to another application so Codex loses focus.
5. Click back into Codex.
6. Observe that MCP child processes are started again and a fresh MCP handshake happens.

What is the expected behavior?

_No response_

Additional information

_No response_