openclaw - 💡(How to fix) Fix Codex app-server user MCP projection drops OAuth config for HTTP MCP servers

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

OAuth-backed user MCP servers can work correctly through OpenClaw's MCP runtime, but fail to appear as first-class/native tools in a native Codex app-server session because the Codex MCP projection drops OpenClaw MCP metadata such as auth, transport, oauth, and toolFilter.

In the observed case, OpenClaw can authenticate and list all Robinhood MCP tools, but the Codex thread binding receives only a bare URL:

{
  "mcp_servers": {
    "robinhood-trading": {
      "url": "https://agent.robinhood.com/mcp/trading"
    }
  }
}

That leaves Codex without the OAuth/session metadata OpenClaw used to authenticate, so the tools do not show up via Codex native tool search / tool_search.

Root Cause

OAuth-backed user MCP servers can work correctly through OpenClaw's MCP runtime, but fail to appear as first-class/native tools in a native Codex app-server session because the Codex MCP projection drops OpenClaw MCP metadata such as auth, transport, oauth, and toolFilter.

Code Example

{
  "mcp_servers": {
    "robinhood-trading": {
      "url": "https://agent.robinhood.com/mcp/trading"
    }
  }
}

---

{
  "mcp": {
    "servers": {
      "robinhood-trading": {
        "url": "https://agent.robinhood.com/mcp/trading",
        "transport": "streamable-http",
        "auth": "oauth",
        "toolFilter": {
          "include": ["get_accounts", "get_portfolio", "review_equity_order"]
        }
      }
    }
  }
}

---

openclaw mcp probe robinhood-trading --json

---

{
  "servers": {
    "robinhood-trading": {
      "tools": 22,
      "listChanged": { "tools": true, "resources": true, "prompts": true }
    }
  },
  "diagnostics": []
}

---

{
  "url": "https://agent.robinhood.com/mcp/trading"
}
RAW_BUFFERClick to expand / collapse

Summary

OAuth-backed user MCP servers can work correctly through OpenClaw's MCP runtime, but fail to appear as first-class/native tools in a native Codex app-server session because the Codex MCP projection drops OpenClaw MCP metadata such as auth, transport, oauth, and toolFilter.

In the observed case, OpenClaw can authenticate and list all Robinhood MCP tools, but the Codex thread binding receives only a bare URL:

{
  "mcp_servers": {
    "robinhood-trading": {
      "url": "https://agent.robinhood.com/mcp/trading"
    }
  }
}

That leaves Codex without the OAuth/session metadata OpenClaw used to authenticate, so the tools do not show up via Codex native tool search / tool_search.

Environment

  • OpenClaw: 2026.6.1 (2e08f0f)
  • Codex CLI: 0.137.0
  • Runtime: native Codex app-server harness
  • MCP server type: HTTP/streamable HTTP with OpenClaw OAuth auth

Reproduction

  1. Configure an HTTP MCP server under mcp.servers with OAuth auth, for example:
{
  "mcp": {
    "servers": {
      "robinhood-trading": {
        "url": "https://agent.robinhood.com/mcp/trading",
        "transport": "streamable-http",
        "auth": "oauth",
        "toolFilter": {
          "include": ["get_accounts", "get_portfolio", "review_equity_order"]
        }
      }
    }
  }
}
  1. Complete OAuth with openclaw mcp login robinhood-trading.
  2. Verify OpenClaw MCP runtime can list tools:
openclaw mcp probe robinhood-trading --json

Observed probe result in this case:

{
  "servers": {
    "robinhood-trading": {
      "tools": 22,
      "listChanged": { "tools": true, "resources": true, "prompts": true }
    }
  },
  "diagnostics": []
}
  1. Start or refresh a native Codex app-server session using the same agent.
  2. Search for the MCP tools from the Codex tool surface, e.g. search for robinhood.

Actual behavior

  • openclaw mcp probe robinhood-trading --json reports the server is reachable and exposes 22 tools with no diagnostics.
  • The native Codex turn does not expose/search those tools as first-class callables.
  • The session's Codex app-server binding shows the user MCP server projected as only:
{
  "url": "https://agent.robinhood.com/mcp/trading"
}
  • Local reproduction of the projection helper shows the same loss of metadata: normalizeCodexMcpServerConfig / the Codex MCP projection emits only the URL for this server.

Expected behavior

One of these should happen:

  1. OAuth-backed OpenClaw MCP servers should be exposed to native Codex sessions through an OpenClaw-authenticated bridge/materializer so Codex can search and call the filtered tools without needing raw OAuth details; or
  2. The Codex MCP projection should preserve/pass through enough auth/transport metadata for Codex to authenticate and list tools correctly, if Codex supports that path; or
  3. OpenClaw should detect that this MCP server cannot be safely projected natively and surface a diagnostic instead of silently giving Codex an unusable bare URL.

Suspected cause

The OpenClaw MCP runtime/materializer can authenticate and list the tools, but the Codex app-server user MCP projection path appears to normalize mcp.servers.* down to Codex-native mcp_servers using only common launch fields such as url, command, args, and env.

For OAuth HTTP MCP servers, that projection drops the OpenClaw-owned auth/session/filter metadata. The resulting Codex-native MCP config is not equivalent to the working OpenClaw MCP runtime config.

Notes

  • This report intentionally does not include tokens or account data.
  • A simple openclaw mcp reload or fresh turn did not fix it; the binding regenerated but still contained only the bare URL.
  • plugins.entries.codex.config.codexDynamicToolsLoading was set to "searchable"; switching it to "direct" may help debug dynamic tool payloads but does not address the dropped OAuth MCP projection metadata.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

One of these should happen:

  1. OAuth-backed OpenClaw MCP servers should be exposed to native Codex sessions through an OpenClaw-authenticated bridge/materializer so Codex can search and call the filtered tools without needing raw OAuth details; or
  2. The Codex MCP projection should preserve/pass through enough auth/transport metadata for Codex to authenticate and list tools correctly, if Codex supports that path; or
  3. OpenClaw should detect that this MCP server cannot be safely projected natively and surface a diagnostic instead of silently giving Codex an unusable bare URL.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING