Custom child agents report collaboration tools despite agents.enabled=false (Windows Desktop, multi-agent v2)

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

The App UI version was not captured in the sanitized diagnostic. The actual Desktop-bundled host executable and tested child session headers both report 0.154.0-alpha.6.2. Child turn metadata reports multi_agent_version=v2.

The separate PATH CLI reports 0.146.0; it was not the runtime used for this reproduction.

What subscription do you have?

Not captured in the sanitized diagnostic.

What platform is your computer?

Windows, x64. Observations were made on September 12, 2026.

What issue are you seeing?

Two native custom child roles, sol_max and luna_max, report that collaboration tools remain visible even though both role files contain:

[agents]
enabled = false

The children run with the expected pinned model/effort, receive their role's instruction prohibiting further delegation, and return useful results. Fully restarting Desktop and creating new children does not remove the reported tool exposure.

Evidence boundary: tool visibility is reported by the children and received by the parent. We have not captured the server-side tool registry. No child invoked delegation, and no successful nested spawn or invocation rejection is alleged. This report requests investigation of configuration precedence/tool advertisement; it does not establish a specific host defect or a successful permission bypass.

What steps can reproduce the bug?

The observed parent/project settings are:

[agents]
enabled = true
max_concurrent_threads_per_session = 6

One selected role file is:

name = "sol_max"
description = "Bounded execution worker for a selected Sol profile. Not an architect, ambiguous planner, final reviewer, or delegation controller."
model = "gpt-5.6-sol"
model_reasoning_effort = "max"
developer_instructions = """
Complete only the bounded task assigned by the parent Coordinator.
Do not expand scope, redefine architecture, or make the final acceptance decision.
Return a concise result with relevant verification evidence.
Return ambiguity, conflicts, and architecture decisions to the parent Coordinator.
Do not spawn, organize, or delegate to other agents.
"""

[agents]
enabled = false

The Luna role uses name = "luna_max", model = "gpt-5.6-luna", effort max, the same bounded-task developer instructions and the same disabled-agents setting.

Both project-scoped and personal copies exist in the observed setup; their corresponding files are byte-identical. This was not an isolated project-only versus personal-only comparison.

1. Start a Desktop task that discovers the native custom roles.
2. Create direct children with agent_type=sol_max and agent_type=luna_max, without direct model or reasoning-effort overrides.
3. Assign disjoint, useful read-only checks (policy/template comparison and role-file/configuration comparison). Also request the children's actually available tool names, without invoking delegation or inferring tools from configuration text.
4. Verify parent-visible model/effort and depth-1 parentage. Receive the useful outputs and tool reports.
5. Fully exit and reopen Desktop, then repeat with fresh child identities.

Observed before and after restart:

• Sol runs as gpt-5.6-sol/max and reports collaboration.spawn_agent, followup_task, send_message, interrupt_agent, list_agents, and wait_agent.
• Luna runs as gpt-5.6-luna/max and reports at least collaboration.spawn_agent and collaboration.followup_task.
• Both receive the no-delegation role instruction; this rules out complete role-loading failure, but not an individual setting being overridden.
• No grandchildren are created. No nested tool call is attempted.
• A parent snapshot confirms two direct children running concurrently. Six-child capacity and overflow checks were not run after the tool-absence check failed.

What is the expected behavior?

Custom agents with agents.enabled=false should not receive multi-agent tools, consistent with:

• Subagent configuration: custom role files are configuration layers and can override supported normal session settings.
• Configuration reference: agents.enabled enables/disables multi-agent tools.

If Desktop v2 deliberately advertises these tools while enforcing a separate invocation guard, please clarify that behavior and provide an authoritative way to verify it.

Additional information

Read-only diagnostics inspected the exact host's experimentally exported app-server schema:

• config/read accepts cwd/includeLayers, not a child/thread selector.
• thread/read does not expose a typed effective agents setting or complete native tool registry.
• server/diagnostics exposes process memory and numeric gauges, not a typed child configuration/tool-registry response.
• Existing session records did not serialize a complete tool registry.

No additional daemon, proxy connection, credential inspection, or nested-spawn probe was used to fill this gap.

Could maintainers inspect, for the same fresh child and its continuation:

1. The final effective agents.enabled value and the winning configuration layer.
2. The actual collaboration tool definitions emitted to the model.
3. Whether a separate invocation-time guard exists.

Impact: the tool-absence acceptance gate for bounded leaf workers cannot pass in the observed Desktop environment. Native model selection and useful execution work. Root cause remains unconfirmed.

This report contains no private filesystem paths, session identifiers, credentials, or raw session attachments.

Start with the custom role files for sol_max and luna_max, then inspect the app-server config/read and thread/read paths described in the report for effective child configuration. Compare the winning agents.enabled value, emitted collaboration tool definitions, and any invocation-time guard for a fresh child and continuation. Done means identifying the configuration or enforcement behavior and documenting or correcting the mismatch with agents.enabled=false.