Repository navigation
V2: revisit tool plugin APIs and execute integration architecture #35364
Description
Activity
I traced the current V2 path at f0ed4f6: built-ins, plugin tools, and MCP tools already register through Tool.Service.transform. Tool.snapshot filters that set for the request, then derives the CodeMode catalog and execute. The direction recorded in #36196—ordinary tools are canonical and their authors need not know CodeMode exists—supports keeping this boundary.
I suggest treating execute as a request-scoped projection of the filtered tool set, while keeping normal tools on the common plugin registration path. The remaining narrow refactor is to route the generated execute entry through the same snapshot dispatch used for direct tools, then cover permission visibility and late calls, nested call identity/progress, interruption and errors, and metadata/file forwarding in focused tests. This avoids adding a second public tool type or a CodeMode requirement to plugin authors. Broader plugin capabilities in #34957 and the attachment/cancellation behavior in #47458 can keep their separate scopes.
Could the core team confirm that this is the intended long-term API boundary for #35364?
Summary
Revisit the V2 tool APIs introduced to integrate CodeMode
execute, and restructure the integration so it follows V2's intended plugin, registry, runner, and event patterns.The current implementation works, but parts of the integration are intentionally expedient. Before treating it as the long-term pattern, we should review the public/internal tool APIs and remove special-case or synthetic wiring we do not want other tools to copy.
Review scope
executeshould be a normal tool plugin, a registry/materialization adapter, or another explicit abstractionAcceptance criteria
executeexecuteis implemented through that shape without one-off registry/runner hooksRelated
executeintegrationSource: https://discord.com/channels/1391832426048651334/1520962938733723720/1523078773669367919