[Windows] custom remote MCP is discovered, first call says tool disabled, then namespace disappears

What version of the Codex App are you using?

Windows package: OpenAI.Codex_26.901.4073.0_x64__2p2nqsd0c76g0
Bundled CLI: codex-cli 0.153.1

What platform are you using?

Windows x64, OS build 26200.

What issue are you seeing?

A working custom remote MCP app can transiently disappear at the Codex/ChatGPT tool-binding boundary even though the MCP server remains healthy and its tool schema is unchanged.

Observed sequence in a fresh/current desktop chat:

1. Connector/tool discovery exposes the custom MCP namespace and its start_process, read_output, and kill_process tools.
2. The first real start_process invocation is rejected by the client/harness with the exact message: The MCPv3 tool has been disabled.
3. Immediate connector rediscovery no longer includes the MCP namespace at all.
4. The same MCP app later reappears and discovery -> invocation succeeds again, with no app reconfiguration, MCP server restart, OAuth reset, endpoint change, or tool-definition change.

This is not a server-arrived MCP error. For the rejected call, the MCP server's request telemetry has no matching /mcp arrival or process-launch event. During the same interval, other already-active chats continued making successful MCP calls to the same backend, and both local and public health endpoints remained HTTP 200.

Why this does not look like the documented frozen-tool-snapshot case

The exposed MCP tool-definition source had not changed for more than a day before the incident. The tool-definition owner last changed on September 3; the failure reproduced on September 5. Later implementation-only changes did not alter the tool names or schemas. When the namespace returned, the same tool schema worked without an admin refresh.

Expected behavior

If a custom MCP app/action is enabled and its approved tool snapshot is unchanged, discovery and invocation should remain consistent. If a policy or safety layer disables an action, the client should return a stable, attributable reason without transiently removing the entire namespace from subsequent discovery.

Additional boundary evidence

After the incident, the same desktop process generation repeatedly exposed and invoked the MCP successfully. Current production telemetry also shows normal transport health and no corresponding 4xx/5xx server failures. This makes local transport/server recovery an ineffective workaround for the failure mode because the rejected invocation never reaches the MCP server.

Related but apparently distinct Windows issues include plugin disappearance (#27152, #28537) and an OAuth-related permanently disabled MCP connector (#38198). This report is specifically the transient discovered -> invocation says disabled -> namespace disappears -> later returns without local changes sequence.

No file or test is named. Start by tracing the Windows desktop MCP discovery and invocation path around the disabled-tool response, using the supplied sequence and server telemetry to distinguish client-side state from transport failure. Reproduce the discovered-to-disabled-to-absent-to-restored sequence, then add a regression check for stable discovery and invocation.