MCP Server for Plugin not being installed on Codex Desktop App for Windows

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #26659

Powered by Codex Action

Still a problem with Version 26.602.71036 • Released Jun 8, 2026. ☹️

Still a problem with Version 26.609.30741 • Released Jun 11, 2026. ☹️

Still a problem with Version 26.609.41114 • Released Jun 12, 2026. ☹️

I discovered that the OAuth callback wasn't working because of AppContainer Isolation. Specifically, Codex needs an exemption.

Here is exactly what is happening under the hood, why it works on macOS/Web but fails on Windows, and how to fix it.
---

The Root Cause: AppContainer Isolation

Windows apps distributed via the Microsoft Store, or packaged using MSIX / UWP, run inside a highly secure, sandboxed environment called an AppContainer.

By default, network isolation rules prevent AppContainers from sending network traffic to the local machine (127.0.0.1 or localhost). This security feature is called Loopback Block.

• The Problem: When your AI agent (like Codex Desktop) spawns an OAuth flow, it opens your default browser to authenticate. The OAuth provider then redirects back to your local machine (e.g., http://localhost:54321/callback). Your browser tries to hand that authorization code back to the desktop app listening on that ephemeral port, but Windows blocks the cross-process communication into the AppContainer, causing the callback to time out or fail.
• Why Mac/Web works: macOS doesn't impose this specific loopback restriction on sandboxed apps by default, and the web environment handles OAuth redirection entirely within the browser context.

---

The Fix: Enable Loopback Exemption

To fix this, you need to explicitly tell Windows to exempt the specific application from the loopback restriction. You can do this either via the command line or a GUI tool.

Method 1: The Command Line (Fastest)

You will need to use Windows CheckNetIsolation.exe via an Elevated Command Prompt or PowerShell (Run as Administrator).

First, you need to find the AppContainer Name or Package Family Name (PFN) of your desktop client.

1. Open PowerShell as Administrator and run this command to find the PFN for Codex or your specific agent:

Get-AppxPackage *Codex* | Select-Object Name, PackageFamilyName

(Replace *Codex* with the relevant name if looking for a different client).

1. Once you have the PackageFamilyName (which usually looks something like CompanyName.AppName_hash), run the following command to grant the exemption:

CheckNetIsolation.exe LoopbackExempt -a -n="YOUR_PACKAGE_FAMILY_NAME"

Method 2: The GUI Way (Easiest)

If you don't want to hunt for Package Family Names in PowerShell, Microsoft provides a built-in utility UI, or you can use a popular community tool.

Option A: Windows Built-in UI (If available on your build)

1. Press Win + R, type CheckNetIsolation.exe LoopbackExempt -display (or search for "Loopback Exemption Manager" in your settings depending on your Windows 11 update).

Option B: Using Fiddler's Loopback Utility (Recommended)

1. Download and open Fiddler Classic (or just the standalone "EnableLoopback Utility" if you have it).
2. Click the WinConfig button in the top left toolbar.
3. A window titled AppContainer Loopback Exemption Utility will open, listing every isolated app on your machine.
4. Find Codex Desktop (or your specific AI Agent client) in the list, check the box next to it.
5. Click Save Changes.

---

Verification

Once you have applied the exemption using either method, you can verify it took effect by running:

CheckNetIsolation.exe LoopbackExempt -s

Look through the returned list to ensure your application's package name is present.

Restart your AI Agent client, kick off the OAuth flow again, and the browser callback to your ephemeral localhost port should now pass right through the Windows sandbox firewall without issue.

---

Shout out to #19685 because it spelled out the command:

CheckNetIsolation LoopbackExempt -a -n="OpenAI.Codex_2p2nqsd0c76g0"

_Knowing what we know now, what does Codex need to do to avoid needing to add this exemption (which requires Admin privileges)?_
---
To fix this so that users don't have to break out PowerShell or Fiddler, the team developing Codex (or any MSIX-packaged desktop AI Agent) has a few paths they can take.

Because Windows deliberately makes it hard for sandboxed apps to listen for inbound localhost traffic, the solution is either configuring the application manifest correctly or changing how the OAuth handshake returns its data.

Here is what the Codex development team can do to handle this seamlessly:

---

Path 1: Switch from Loopback to Custom URL Protocols (The Best Practice)

The cleanest, most secure way to avoid the loopback problem entirely is to stop using http://localhost:[port] as the OAuth redirect URI on desktop apps.

Instead, Codex should register a Custom URL Protocol (e.g., codex:// or cowork://) in its Windows app manifest.

<!-- Example manifest registration -->
<uap:Extension Category="windows.protocol">
  <uap:Protocol Name="codex">
    <uap:DisplayName>Codex Desktop Callback</uap:DisplayName>
  </uap:Protocol>
</uap:Extension>

• How it works:

1. The app triggers the OAuth flow and tells the identity provider that its redirect URI is codex://oauth-callback.
2. When the browser finishes authentication, it redirects to that custom URI.
3. Windows recognizes the protocol and hands the raw token or auth code directly back to the running Codex process as an activation argument.

• Why it wins: It skips the local TCP network stack completely, avoiding the AppContainer sandbox firewall entirely.

---

Path 2: Declarative Manifest Capabilities (If sticking to HTTP Loopback)

If Codex must use a local HTTP web server for the callback (e.g., because they are sharing a code engine between Web, Mac, and Windows and don't want to refactor the OAuth flow), they can ask Windows for specific exemptions inside their AppxManifest.xml.

They need to inject the privateNetworkClientServer capability alongside internetClient. While this doesn't automatically lift the loopback block for every type of internal communication, pairing it with the modern Windows App SDK / AppContainer loopback extensions allows the packaged application to properly bind and receive local incoming loopback traffic.

<Capabilities>
  <Capability Name="internetClient" />
  <Capability Name="privateNetworkClientServer" />
</Capabilities>

---

Path 3: Programmatic Loopback Exemption via Installer/First Run

If they are distributing the MSIX via an installer or a wrapper that runs with elevated privileges during setup (or if they use the Package Support Framework), they can actually execute the programmatic API equivalent of what you did manually.

Windows provides a native C++ function called NetworkIsolationRegisterForAppContainerChanges and NetworkIsolationSetAppContainerConfig inside FirewallAPI.dll.

When Codex launches or installs, it can check if it has loopback access. If it doesn't, it can trigger a one-time UAC prompt asking the user for permission to configure its networking environment, applying the exemption code-side using its own Package Family Name:

// Concept of what their desktop backend would execute
NetworkIsolationSetAppContainerConfig(dwNumAssignedRecords, pAppContainerRecords);

Which option should they choose?

Path 1 is strongly encouraged. Modern security architectures (like RFC 8252 for native apps) heavily favor Custom URL Schemes or System Brokers over local ephemeral web servers because they don't leave random ports open on the user's loopback interface.

Even after adding the _Loopback Exemption_, and then re-installing from scratch, the Composio MCP server is _still not automatically installed_ for the Plugin. (It clearly knows the .mcp.json file because it does the OAuth challenge, and lists the Composio MCP Server on the Plugin page, but doesn't _enable_ it.) And I'm running the latest Version 26.609.71450 • Released Jun 15, 2026. ☹️

Running into this problem on MacOS now with the latest Version 26.623.42026 • Released Jun 26, 2026.

Using Version 26.623.70822 • Released Jun 29, 2026 on Windows and still having this problem. I even changed the MCP Server to use an API Key instead of OAuth. This should be easier, yet still a problem.

Plugin-defined MCP installation needs an explicit install/provisioning state machine rather than “plugin installed” implying “MCP server attached.”

I would persist and surface: plugin id/version, discovered .mcp.json digest, auth status, install attempt id, resolved command/env, connection state, tool-list result, and whether the server was made available to new sessions. If auth succeeds but MCP attach does not, the UI should show that split state and offer a retry/reconcile action.

I maintain Better Agent (https://github.com/ofekron/better-agent), where plugin/provider capability discovery, auth, server process ownership, and effective tool catalog are separate states. If useful, a star helps other desktop-agent plugin builders find it.