›_ Codex Issues
Codex Issues / #36599

[MCP Apps] App-origin tools/call bypasses model-only visibility in Codex Desktop

Open 💬 0 comments Opened Aug 2, 2026 by ipedro

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

26.727.40816

What subscription do you have?

ChatGPT Max

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

An MCP App iframe can send a raw tools/call for a tool declared with _meta.ui.visibility: ["model"], and Codex Desktop forwards the request to the MCP server. The server receives the request and the model-only tool executes successfully.

The MCP Apps specification says hosts must reject App-origin calls for tools whose visibility does not include "app". In this run, rejection did not happen at the host boundary.

Normal rendering and local UI interaction remained passive and produced no extra server request. The failure appeared only when an adversarial raw App-origin bridge message was injected.

What steps can reproduce the bug?

  1. Register an MCP tool and associate it with an MCP App resource. Declare the tool as model-only:
{
  "name": "model_only_probe",
  "inputSchema": {
    "type": "object",
    "properties": {},
    "additionalProperties": false
  },
  "_meta": {
    "ui": {
      "resourceUri": "ui://example/probe.html",
      "visibility": ["model"]
    }
  }
}
  1. Attach the server in Codex Desktop and render the App resource from a normal model-origin tool result.
  2. From the App frame, send a raw MCP request through the host bridge:
window.parent.postMessage({
  jsonrpc: "2.0",
  id: "visibility-probe-1",
  method: "tools/call",
  params: {
    name: "model_only_probe",
    arguments: {}
  }
}, "*");
  1. Observe the MCP server transport.

Actual result: the server receives tools/call and the model-only tool executes.

The same harness also observed that raw App-origin requests for unknown and cross-server-style tool names reached the MCP proxy before returning an implementation error. This suggests visibility and target validation are occurring too late or are absent at the App-to-host boundary.

What is the expected behavior?

Codex Desktop should reject the App-origin request before forwarding anything to the MCP server because the tool visibility omits "app".

The relevant normative requirement is in the stable MCP Apps specification under Tool Visibility: https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/2026-01-26/apps.mdx#visibility

Additional information

  • Codex Chromium version observed: 150.0.7871.182.
  • App bridge identified itself as chatgpt version 0.0.1.
  • The test server was local stdio and the probed tool was read-only.
  • The shipped App used for discovery is passive, self-contained, declares no network origins, and exposes no tool-call UI path, so its normal behavior is unaffected.
  • The server saw different proprietary metadata shapes for model-origin and App-origin requests, but those fields are not a documented authorization contract and should not be required for server-side mitigation.
  • Duplicate searches immediately before filing found MCP App rendering and lifecycle issues, but no issue covering App-origin enforcement of _meta.ui.visibility.

View original on GitHub ↗