Repository navigation
V2: revisit tool plugin APIs and execute integration architecture #35364
Description
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
- audit the tool APIs and seams added for feat(core): expose deferred tools through execute #35361
- decide whether
executeshould be a normal tool plugin, a registry/materialization adapter, or another explicit abstraction - align deferred-tool discovery with the supported plugin API
- remove special-case Core/MCP wiring where a general mechanism should exist
- verify permission propagation, child-call identity, progress, cancellation, errors, metadata, and attachments
- keep nested execution observable without leaking CodeMode-specific concerns into the generic tool API
- define which APIs are public for plugins versus internal implementation details
- add focused architecture and integration tests around the chosen shape
Acceptance criteria
- the team agrees on the long-term V2 tool/plugin API shape used by
execute executeis implemented through that shape without one-off registry/runner hooks- Core tools, MCP tools, and external plugin tools follow consistent discovery and execution rules
- progress support composes with the separate progressive-tool-update design
- current CodeMode behavior remains covered by tests
Related
- feat(core): expose deferred tools through execute #35361 — current V2
executeintegration - feat(codemode): add confined execution package #35118 — V2 CodeMode package
- feat(codemode): add OpenAPI tool adapter #35362 — V2 OpenAPI tool adapter
- V2: add tool registration to Promise plugins #34489 — V2 plugin tool registration
Activity
Dante-dan commentedon Sep 26, 2026
I traced the current V2 path at
f0ed4f6: built-ins, plugin tools, and MCP tools already register throughTool.Service.transform.Tool.snapshotfilters that set for the request, then derives the CodeMode catalog andexecute. The direction recorded in #36196—ordinary tools are canonical and their authors need not know CodeMode exists—supports keeping this boundary.I suggest treating
executeas 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 generatedexecuteentry 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?