›_ Codex Issues
Codex Issues / #16527

Subagent MCP definition is ignored

Open 💬 3 comments Opened Apr 2, 2026 by meaningfool
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.325.31654 (1272)

What subscription do you have?

Plus

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Here is the definition of a subagent below provided access to an MCP that is not declared in config.toml. The subagent when spawned does not have access to this MCP

name = "logfire_analyst"
description = "Use when a task depends on analyzing Logfire traces, telemetry, or observability signals and relating them to the checked-out codebase."
model = "gpt-5.4"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
Investigate telemetry-heavy questions through Logfire MCP and the local codebase.
Stay in analysis mode.
Distinguish observed telemetry, observed code, and inference.
Report evidence, code-path explanation, ranked hypotheses, remediation options, and eval or observability improvements.
Do not edit code, configuration, or git state.
If MCP authentication or data access fails, say so plainly and continue with repo-only reasoning where possible.
Be explicit about confidence and limits.
Treat Logfire MCP as a narrow, remote-first interactive surface.
If a request appears blocked by MCP age limits or missing tool coverage, say so instead of over-promising.
"""

[mcp_servers.logfire]
url = "https://logfire-eu.pydantic.dev/mcp"

<img width="786" height="400" alt="Image" src="https://github.com/user-attachments/assets/6b9b8558-2c79-4b04-ac38-58ee03ddc583" />

What steps can reproduce the bug?

  1. Define a subagent
  2. Give it access to a MCP that is not provided in config.toml
  3. Spawn the subagent

What is the expected behavior?

The subagent should have access to the MCP as per what the documentation states

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #16475

Powered by Codex Action

meaningfool · 4 months ago

This might be 2 separate bugs or they might have a single root cause: possibly MCPs don't work at all in subagents. I could test that adding the same MCP at the top-level did not solve the issue:

<img width="752" height="321" alt="Image" src="https://github.com/user-attachments/assets/a4314142-baae-4ea5-8438-8407a449c253" />

norika1207-lab · 2 months ago

A diagnostic that would make this easier to isolate: have each subagent/session report the MCP surface it actually received, separately from the parent session configuration.

There are several different failure modes that look the same from the user side:

  • the MCP server is configured globally but not inherited by the subagent;
  • the subagent receives the server definition but tool discovery fails;
  • the tool exists but is filtered by permissions/sandbox policy;
  • the parent can call the MCP tool, but delegated agents get a reduced tool surface by design.

If the runtime emitted a small per-agent capability snapshot, users could tell whether this is a config inheritance bug or an intentional isolation boundary. Something like:

{
  "agent": "subagent-name",
  "mcp_servers_configured": ["github", "filesystem"],
  "mcp_servers_started": ["github"],
  "tools_exposed_count": 12,
  "filtered_reason": "sandbox_policy|auth_missing|not_inherited|startup_failed"
}

That would also help document the desired security model: whether subagents should inherit all parent MCP capabilities, inherit none, or require explicit per-subagent allowlists.