Private remote MCP plugin can appear installed or connected while Codex exposes no callable tools

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

Codex Desktop version not captured; bundled runtime reports codex-cli 0.146.0

What subscription do you have?

Not captured

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

A private remote MCP plugin can complete server-side setup and OAuth successfully, while the Codex app still fails to expose the plugin's tools in active threads.

The plugin appeared installed or connected, but the runtime could report states equivalent to "not installed", "unknown tool", or no available MCP namespace. Reconnecting, refreshing, or opening a new conversation did not consistently repair the active tool surface; a full app restart or reinstall could change the result.

The remote MCP server itself was healthy: its endpoint responded, authentication completed in some flows, and its tools worked when tested outside the affected interactive app surface. A separate workflow using the same publishing backend remained reliable.

The plugin also exposed a host-compatibility problem: its UI bridge depended on host-specific file and follow-up APIs, so data tools and the visual widget could fail independently. Repeated implementation changes were needed to separate data tools from render tools, add output schemas, and handle stale plugin/tool metadata.

What steps can reproduce the bug?

1. Create a private remote HTTP MCP server with OAuth and several tools, including read-only and write actions.
2. Add an optional UI/template resource for preview or approval.
3. Verify independently that the server responds and that its tools can be listed or called.
4. Install or connect the plugin in Codex Desktop.
5. Complete OAuth or reconnect the app.
6. Open a new Codex thread and ask the model to call one of the plugin tools.
7. Inspect the active tool/search surface.
8. Repeat after reconnecting, refreshing, opening a new conversation, and restarting the app.

Observed results can include:

• The plugin appears installed while tools are absent.
• The app appears connected while required MCP tools are unavailable.
• Tool calls return "unknown tool".
• New conversations do not refresh the tool inventory.
• Skill metadata, UI templates, and MCP tools can become stale or disagree.
• A full restart may be required before tools appear.
• UI resources can fail even when data-only tools work.

What is the expected behavior?

Codex should maintain one truthful integration state covering plugin installation, OAuth completion, MCP reachability, tool discovery, tool mounting into the current thread, and UI/template availability.

If any stage fails, Codex should show the exact failed stage and provide a reliable recovery action. A new conversation should either refresh the tool inventory or clearly state that a full restart is required.

Plugin tools should remain callable without optional UI extensions. Host-specific APIs should be treated as progressive enhancement rather than a dependency for the core MCP workflow.

Additional information

The backend and publishing workflow were tested independently and were not the primary failure point. No production article was published during the plugin tests.

This issue is focused on the combined state mismatch for a hosted remote OAuth MCP plugin in the Codex App. Related reports address narrower parts of the behavior, including remote OAuth lifecycle, Desktop tool exposure, plugin installation state, and stale plugin inventory: #30716, #25843, #20710, #32636, and #35006.

No personal names, private domains, project identifiers, local paths, credentials, or screenshots are included here.