Codex runtime does not expose configured MCP tools in agent-compose run

[0x0334]

Codex runtime does not expose configured MCP tools in agent-compose run

Summary

In agent-compose v2607.8.0 and v2607.9.0, a project can declare an MCP server and
the Guest Codex CLI can list that server when invoked directly. However, a Codex model
started through agent-compose run <agent> --prompt ... reports that the configured MCP
tool is unavailable. The model session also does not expose a terminal tool.

This prevents the model from invoking an MCP tool even though the MCP server and transport
work in direct control tests.

Environment

• Docker driver
• Guest image: ghcr.io/chaitin/agent-compose-guest:v2607.8.0
• Reproduced again with daemon and Guest at v2607.9.0
• Provider: codex
• MCP transport: local stdio server

No private endpoint, credential, internal hostname, project name, or host-specific path is
required for this report.

Minimal configuration

name: mcp-repro

workspaces:
  source:
    provider: local
    path: .

mcp_servers:
  example-search:
    type: local
    command: python3
    args:
      - /workspace/mcp/stdio_server.py

agents:
  repro:
    provider: codex
    image: ghcr.io/chaitin/agent-compose-guest:v2607.9.0
    driver:
      docker: {}
    workspace:
      name: source
    mcp_servers:
      - example-search

The stdio server can be any local MCP server that exposes one harmless read-only tool,
for example search_demo.

Reproduction

Run a prompt that explicitly requests the configured tool:

agent-compose --file agent-compose.yml --json run repro --rm \
  --prompt 'Call the example-search/search_demo MCP tool once and report its result.'

Expected:

1. The Codex run emits an MCP tool-call event.
2. The stdio server receives a JSON-RPC tools/call request.
3. The model reports the tool result.

Actual on both tested releases:

The configured MCP tool is not available in this session.

The MCP server receives no request from the model run.

Control tests

The same Guest can list the MCP server with the Codex CLI directly. The same stdio server
also succeeds when invoked directly, and agent-compose explicit command mode can execute a
fixed client command successfully. These controls show that the MCP server, Guest image,
Docker driver, and transport are functional; the failure is specific to the model runner's
tool exposure boundary.

Additional evidence

The runtime builds prompt options containing an MCP configuration, while the Codex runner
starts the Codex SDK without visibly passing that resolved MCP configuration into the SDK
thread/session. A wrapper that adds equivalent -c mcp_servers... overrides was also tested;
the wrapper was invoked, but the model still reported no MCP tool on both releases.

Impact

Agents that depend on MCP cannot perform their intended model-driven tool calls. A model
prompt also cannot reliably fall back to a shell command when no terminal tool is exposed.

Suggested fix

Please ensure the Codex runner passes the resolved MCP configuration into the Codex SDK/thread
configuration, or otherwise guarantees that the SDK process receives the same MCP configuration
shown by codex mcp list.

A regression test should assert that agent-compose run:

1. emits an MCP tool-call event for a configured local server;
2. delivers the JSON-RPC tools/call request to that server;
3. exposes the tool to the model without a user-managed wrapper; and
4. reports a clear startup error when the server cannot start.

Security

This report intentionally excludes credentials, private endpoints, internal hostnames/IPs,
project identifiers, sandbox/run identifiers, and application-specific data.

[fuchencong]

We attempted to reproduce this with both the current source and the exact v2607.9.0 release topology. Under our regression provider/model configuration, the MCP tool call succeeds. Below is the complete sanitized setup so the reporter can compare it with the failing environment.

Result summary

We tested these combinations:

1. current main daemon + freshly rebuilt agent-compose-guest:latest (twice);
2. current main daemon + ghcr.io/chaitin/agent-compose-guest:v2607.9.0;
3. extracted v2607.9.0 daemon/CLI binary + ghcr.io/chaitin/agent-compose-guest:v2607.9.0;
4. literal issue topology and prompt, including the hyphenated example-search name and --rm, with no wrapper and no concurrent codex mcp list.

All valid model runs succeeded. The final literal run produced one tools/call, an mcp_tool_call runtime marker, the fixed tool result, and successful --rm cleanup.

Release information used for the final run:

{
  "version": "v2607.9.0",
  "os": "linux",
  "arch": "amd64",
  "compiled_drivers": ["docker", "boxlite", "microsandbox"]
}

Guest image:

ghcr.io/chaitin/agent-compose-guest:v2607.9.0
local image id: sha256:83934ee8286b01e9f5b2188ea9b983a576d33d9e8717214044a4c35b1bc91478

Provider settings for our final run:

provider: codex
effective model: feature/gpt-5.6-sol
wire protocol: responses

The endpoint and all API keys/tokens are intentionally omitted. They were supplied only to the isolated daemon process.

Exact test topology

mcp-repro/
├── agent-compose.yml
└── mcp/
    └── stdio_server.py

agent-compose.yml:

name: mcp-repro

workspaces:
  source:
    provider: local
    path: .

mcp_servers:
  example-search:
    type: local
    command: python3
    args:
      - /workspace/mcp/stdio_server.py

agents:
  repro:
    provider: codex
    image: ghcr.io/chaitin/agent-compose-guest:v2607.9.0
    driver:
      docker: {}
    workspace:
      name: source
    mcp_servers:
      - example-search

mcp/stdio_server.py:

#!/usr/bin/env python3
import json
from pathlib import Path
import sys

LOG_PATH = Path("/workspace/mcp/requests.jsonl")

def send(request_id, result):
    print(json.dumps({"jsonrpc": "2.0", "id": request_id, "result": result}, separators=(",", ":")), flush=True)

def record(message):
    entry = {"method": message.get("method")}
    params = message.get("params") or {}
    if isinstance(params.get("name"), str):
        entry["name"] = params["name"]
    if isinstance(params.get("arguments"), dict):
        entry["arguments"] = params["arguments"]
    with LOG_PATH.open("a", encoding="utf-8") as stream:
        stream.write(json.dumps(entry, separators=(",", ":")) + "\n")

def handle(message):
    record(message)
    method = message.get("method")
    request_id = message.get("id")
    if request_id is None:
        return
    if method == "initialize":
        send(request_id, {
            "protocolVersion": "2024-11-05",
            "capabilities": {"tools": {"listChanged": False}},
            "serverInfo": {"name": "example-search", "version": "1.0.0"},
        })
    elif method == "tools/list":
        send(request_id, {"tools": [{
            "name": "search_demo",
            "description": "Search the deterministic demo index.",
            "inputSchema": {
                "type": "object",
                "properties": {"query": {"type": "string"}},
                "required": ["query"],
                "additionalProperties": False,
            },
        }]})
    elif method == "tools/call":
        send(request_id, {
            "content": [{"type": "text", "text": "issue-323-exact-tool-ok"}],
            "isError": False,
        })
    elif method == "ping":
        send(request_id, {})
    else:
        print(json.dumps({
            "jsonrpc": "2.0",
            "id": request_id,
            "error": {"code": -32601, "message": f"unsupported method: {method}"},
        }, separators=(",", ":")), flush=True)

for line in sys.stdin:
    try:
        message = json.loads(line)
    except json.JSONDecodeError:
        continue
    if isinstance(message, dict):
        handle(message)

Daemon topology

We used a fresh data root and Docker driver. The relevant daemon environment shape was:

DATA_ROOT=<fresh-test-data>
SANDBOX_ROOT=<fresh-test-data>/sandboxes
AGENT_COMPOSE_SOCKET=<fresh-test-socket>
AGENT_COMPOSE_RUNTIME_BASE_URL=http://<docker-bridge-host>:9768
HTTP_LISTEN=0.0.0.0:9768
RUNTIME_DRIVER=docker
DEFAULT_IMAGE=ghcr.io/chaitin/agent-compose-guest:v2607.9.0
DOCKER_DEFAULT_IMAGE=ghcr.io/chaitin/agent-compose-guest:v2607.9.0
LLM_API_ENDPOINT=<redacted>
LLM_API_PROTOCOL=responses
LLM_API_KEY=<redacted>
LLM_MODEL=feature/gpt-5.6-sol

The listener was exposed only for the isolated local Docker bridge test.

Commands

On a fresh v2607.9.0 daemon, the single run command shown in the issue returns project ... not found. Therefore an applied project is an implicit prerequisite for reaching the model. The reporter's environment must already have had the project applied because it produced a model response.

We used only the public CLI to make that prerequisite explicit:

agent-compose --file agent-compose.yml up

agent-compose --file agent-compose.yml --json run repro --rm \
  --prompt 'Call the example-search/search_demo MCP tool once and report its result.'

No user-managed Codex wrapper was installed. The final literal run did not execute codex mcp list concurrently with the model run.

Because --rm deletes the sandbox, our harness copied mcp/requests.jsonl while the run was active. For manual inspection, the same test can first be run with --keep-running, followed by an explicit sandbox cleanup.

Observed evidence

Captured stdio MCP methods:

{"method":"initialize"}
{"method":"notifications/initialized"}
{"method":"tools/list"}
{"method":"tools/call","name":"search_demo","arguments":{"query":"demo"}}

Sanitized run result:

status: succeeded
duration_ms: 27616

[mcp:example-search/search_demo]
{"query":"demo"}
issue-323-exact-tool-ok

Assertions:

run_exit_zero                         PASS
probe_received_tool_call              PASS
runtime_emitted_mcp_tool_call         PASS
run_returned_probe_result             PASS
rm_removed_sandbox                    PASS

Remaining differences / requested comparison data

The issue does not identify the effective model or upstream wire implementation. provider: codex selects the guest runtime, but it does not guarantee that two installations use the same model or an upstream that preserves the same tool definitions.

The report also says both MCP and terminal tools were unavailable. Since both tool classes were available in our release test, the strongest remaining difference is the model/upstream tool boundary or persisted thread/session state, not the local stdio configuration itself. This is a hypothesis, not a confirmed root cause.

Could the reporter rerun the topology above and share the following sanitized data?

1. agent-compose --json version output and the guest image tag/digest;
2. effective model ID and wire protocol (responses vs chat_completions), without endpoint/key values;
3. whether agent-compose --file agent-compose.yml up was run before the reported command;
4. redacted ~/.codex/config.toml (remove base_url, tokens, headers, and private paths);
5. codex mcp list output;
6. MCP method names observed by the server (initialize, tools/list, tools/call only; no credentials);
7. the sanitized agent-compose run output;
8. whether this was a fresh sandbox/thread or a resumed thread created before MCP configuration changed.

Please do not post API keys, authorization headers, private endpoints, tokens, or private project paths.

At this point we have not changed business code because the failure has not reproduced under the topology above.