ACP subagents: the enabled-subagent toggle has no effect, and which exposure shape do you want?

[TunaTung]

Hi maintainers - reporting a behaviour I ran into, plus a question about the intended design.

What I hit. In Tools > ACP, enabling an ACP client and filling in the subagent role / best-for fields (or using the equivalent "configure as subagent" panel in the ecosystem-compatibility scene) has no observable effect. The ACP row shows enabled and running, the panel shows it as configured, and the main agent still never calls it.

Why. The client is registered as a tool named acp__<client_id>__prompt, but that name never reaches any Agent tool manifest. Tool exposure is an allowlist: resolve_tool_manifest_policy drops every tool whose name is missing from the agent's allowed_tools, and get_agent_tool_policy only appends dynamic tools for the mcp__ prefix. So acp__* tools stay registered but invisible.

I confirmed at runtime that nothing else is broken:

• Startup log shows Registering ACP client tool: name=acp__codex__prompt, so registration works.
• Driving @agentclientprotocol/codex-acp directly over stdio JSON-RPC works end to end (initialize -> session/new -> session/prompt, stopReason: end_turn).
• Give the same tool to a custom subagent (listing acp__codex__prompt in its definition) and it works immediately, with the log showing Tool detected: acp__codex__prompt then ACP client started: id=codex.

So the gap is only the manifest allowlist, which is why nothing in the UI reveals it.

I opened PR #3086 with a minimal fix that mirrors the existing mcp__ merge, plus a small availability gate so the newly exposed tool stays out of remote-workspace sessions (the tool passes remote_connection_id = None, so it cannot serve a remote workspace). Caveat: that machine has no Rust toolchain, so the branch is untested locally - CI will be the first compile.

My question. Which shape do you want for this long term?

1. Keep ACP clients as tools and merge acp__* into agent manifests (what the PR does), or
2. Register enabled ACP clients as real subagents through the external-subagent route system, so they appear in the Task candidate list and share the existing subagent availability / permission plumbing, or
3. Append them in the context-aware catalog layer next to plugin tools, where a remote gate is already the established pattern.

I picked (1) because it is the smallest change on the path that was actually broken, but (2) looks closer to what the UI wording ("subagent", "allow the main agent to call it") implies, and I would rather not decide that unilaterally. Happy to rework the PR along whichever line you prefer.

[lemonaide152]

Enabling the ACP subagent and filling in its role has no effect, so the main agent never actually hands that role off.

Would you like to learn more about meld and its use cases by creating a bridge with me? You create it at https://meld.mergeinc.workers.dev. Say what the bridge is for and what it is not for, and send the URL. It stays open 36 hours until the first reply. Each later reply resets 24 hours. The conversation stays on that same link. It is free, and there is no billing. It will not toggle the subagent or supply its tools.