Custom Agents MCP, sandbox restriction definitions broken

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

• #40042

Powered by Codex Action

We hit the same regression in Codex App 26.818.41509 / embedded Codex 0.149.0-alpha.4.1 with a custom research worker.

The parent config registers one MCP server with 18 state-management tools. The role file narrows that inherited server to an exact six-tool enabled_tools allowlist. After #39299, the selected custom role still receives all 18 inherited tools; the role-local MCP restriction is silently ignored. The role itself is selected correctly and its developer_instructions apply.

This breaks a main/worker authority boundary: task_accept and task_unblock must be main-agent-only, while the worker should only claim/show/register/submit/block/fail. A denylist has the same problem.

Expected bounded behavior: a child role may reduce the tool surface of an MCP server inherited from the parent, but may not add servers or expand the parent's tool set. That preserves the authority goal of #39299 while supporting least privilege. A validation error or explicit warning would also be preferable to silently ignoring unsupported role keys.

This overlaps the longer-term per-agent MCP scoping request in #20135. We are adding a conditional server-side caller guard as a local compatibility fallback; it is not a substitute for host-side tool filtering.

Confirmed on macOS with Codex CLI 0.149.0: a project custom agent that exclusively declares Chrome DevTools MCP receives no mcp__e2e_browser__* tools. The identical profile works on 0.147.0. This directly breaks the documented browser-debugger custom-agent pattern (https://learn.chatgpt.com/docs/agent-configuration/subagents).

Indeed, the fact they broke it is irritating. The fact that there was no announcement, and they have not updated the documentation, is far worse. If you ask codex to write you good subagents, it will plain write them wrong based on the documented capabilities.

Matched macOS CLI 0.149.1 reproduction: custom read-only is ignored and the child can write

This is an enforcement reproduction with a read-only control, not a child self-report. The current custom-agent documentation says custom agents can override the sandbox and that parent sandbox settings are inherited when omitted. Here the role explicitly declares sandbox_mode = "read-only", but that declaration is ignored beneath a workspace-write parent.

Environment:

• Codex CLI 0.149.1 (current npm release)
• macOS 26.6.2, Apple Silicon
• ChatGPT authentication
• isolated temporary CODEX_HOME; Desktop was installed but did not share this home
• approval policy never

Custom role:

name = "reviewer"
model = "gpt-5.6-terra"
model_reasoning_effort = "high"
sandbox_mode = "read-only"

After an initial trust-registration warm-up, I hashed the effective configuration and role file before and after both arms. The hashes were unchanged throughout:

config.toml  040011fbe045334de6a9e729712469bb23580925135644bd108509904127ed7b
reviewer.toml 733492ef8917424548ea7cbe53922beda6af6394e7776c8cd307afc8368b5a7b

| Arm | Parent sandbox | Child rollout metadata | Write probe |
|---|---|---|---|
| Failure | workspace-write | workspace-write; role reviewer; Terra High | apply_patch succeeded |
| Control | read-only | read-only; role reviewer; Terra High | same apply_patch rejected |

Rollout IDs:

• failure child: 01a03c12-87c7-7970-8a61-e94885946bb9
• read-only control child: 01a03c12-f58d-7210-aa93-e4f7bdf62d6f

Only the parent sandbox changed. The selected role, model, reasoning effort, isolated home, role/config contents, approval policy, task, and probe were held constant. The control proves the read-only engine itself works; the failure shows the explicit per-agent sandbox was silently replaced by the broader parent sandbox and the widening was enforceable in practice.

Expected: an explicit sandbox_mode = "read-only" on the selected custom role narrows the child, or spawn fails clearly if that combination is unsupported.

Actual: role/model/effort bind, but the role sandbox does not; the child silently receives workspace-write and can modify the workspace.

I discarded an earlier run because Codex added a project-trust entry during warm-up and changed the config hash. The table above is the clean rerun with identical before/after hashes.