400 "Missing namespace for function_call" for deferred/tool-search tools (e.g. extensions_manage) on 1.0.80

[ms-jb]

Describe the bug

Description

On Copilot CLI 1.0.80, calls to tools discovered via deferred tool search intermittently fail with:

Execution failed: CAPIError: 400 Missing namespace for function_call '<tool_name>'. It does not exist in the default namespace. Round-trip the model's function_call item with its namespace field included. (Request ID: )

Observed against:

• A locally installed extension tool: agenttools-prwatch_pool (plugin prwatch:prwatch)
• A built-in tool: extensions_manage

Both are (or can be) discovered via deferred tool_search_call rather than eager loading, and the model's function_call item appears to lose its namespace field when round-tripped back to CAPI on a subsequent turn, producing the 400 above.

Impact

Any session that discovers the affected tool via deferred tool search becomes unable to invoke it at all, with no recovery path other than avoiding the tool. This is not scoped to third-party extensions — it also hit a built-in tool (extensions_manage), suggesting the root cause is in the deferred-tool-search/round-trip serialization path itself.

Root cause (as best diagnosed locally)

• Tools default defer to auto/tool-search deferral, so they're discovered lazily via tool_search_call, with call-id → namespace mapping carried in serverTools.functionCallNamespaces.
• When that deferred function_call item is replayed on a later request without its namespace field, CAPI rejects it with the 400 above.
• Matches a similar reported issue in a sibling CLI: Namespaced MCP tool calls fail after deferred tool discovery because replayed function_call drops namespace openai/codex#23839 ("Namespaced MCP tool calls fail after deferred tool discovery"), same error text, same likely cause.

Workarounds applied locally

1. Per-extension: set defer: "never" on our own extension's tools so they're eagerly loaded (doesn't help built-in tools).
2. Global: set "toolSearch": false in ~/.copilot/settings.json to disable deferred tool search app-wide. After this, both extensions_manage and the previously-failing extension tool succeeded with no further namespace errors.

Neither is a real fix — (1) doesn't cover built-ins, (2) disables a supported performance feature entirely.

Expected behavior

Deferred tool calls should retain their namespace field when round-tripped back to the model/CAPI on subsequent turns, regardless of whether the tool is built-in or from an installed extension, so toolSearch can stay enabled without risking a 400 on invocation.

Environment

• Copilot CLI version: 1.0.80
• OS: Windows
• Reproduced with: a locally installed plugin extension (prwatch:prwatch) and a built-in tool (extensions_manage)

Related

• Namespaced MCP tool calls fail after deferred tool discovery because replayed function_call drops namespace openai/codex#23839 — same error text and same deferred-tool-discovery/namespace-round-trip root cause in a related CLI.

Suggested fix direction

Cache the call_id → namespace mapping (as captured in serverTools.functionCallNamespaces) and reattach namespace when serializing/replaying the corresponding function_call item on the next request, instead of relying on the model to carry it forward verbatim.

Affected version

1.0.80

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response

[MilkyWay008]

Your root cause read looks right, toolSearch: false is the documented escape hatch so that's a legit workaround, not a hack. Worth linking this to codex#23839 since they share the same namespace round-trip bug, whoever lands that fix can cover both, your call_id \u2192 namespace cache idea is exactly the shape of it. btw, I keep a portable Hermes OTG on a USB as my rescue agent for poking at CLI internals like this, check it, imo it may help you diagnose quicker. https://github.com/MilkyWay008/Hermes-OTG