Delegated task children cannot authenticate HTTP-OAuth MCP servers: <server>/* gets 401, explicit refs work only on claude-fable-5.1 and only for some servers #5437

ustom child agents launched with the native task tool cannot use HTTP-OAuth MCP servers reliably. Two symptoms from the same cause, observed across ~30 delegated runs on 2026-11-10 to 2026-11-12:

1. /* wildcard on an OAuth server → requires authentication in the child. The agent host opens a fresh connection per declared server when a child starts. For HTTP servers it attempts a host-delegated OAuth handoff that never gets a response, falls back to browser OAuth it cannot complete, and sends the request unauthenticated:

The identical three lines are logged for atlassian (https://mcp.atlassian.com/v2/mcp). The parent session calls both servers successfully; the stdio testrail server (env-var credentials) works from every child.

2. Explicit / references behave differently by model and by server. With tools: [..., atlassian/atlassianUserInfo, atlassian/getJiraIssue, ...] (no wildcard): on claude-fable-5.1 the child discovers the tool via tool_search_tool, calls it, and succeeds (7/7 for one agent, 1/1 each for two more profiles). On gpt-6-luna the same agent file discovers the same name and then declines to call it ("no callable invocation interface"), 0/6 attempts — even after instructions explicitly required an attempt. Models were harness defaults; no model override in any failing run. With tools: [..., mabl/get_current_user] on claude-fable-5.1, the child discovers the name and calls it, and the host returns Tool 'mabl-get_current_user' does not exist. So explicit Atlassian refs reach an authorized path that explicit mabl refs do not.

Secondary: tool_search_tool inside a child returns tools not in the child's tools list (e.g. atlassian-executeDestructive, Postman-MCP-*), consistent with #5191.

Affected version:

Agent host copilotVersion 1.0.103-unstable.r41379698026.g3219c66 (from session events), VS Code agent-host client (vscode-agent-host), Windows.

Steps to reproduce the behavior:

Configure https://mcp.atlassian.com/v2/mcp and https://mcp.mabl.com/mcp (both HTTP OAuth) in .vscode/mcp.json; authorize both in the parent session.
Child A: tools: [read, search, vscode/toolSearch, atlassian/] → delegate via task, ask it to call atlassianUserInfo once. Observe requires authentication.
Child B: tools: [read, search, vscode/toolSearch, atlassian/atlassianUserInfo], instructions "discover then call exactly once; a name-only discovery result is not evidence it is uncallable". Delegate with model: "claude-fable-5.1" → success. Delegate with default gpt-6-luna → refuses without attempting.
Child C: tools: [read, search, vscode/toolSearch, mabl/get_current_user], model: "claude-fable-5.1" → Tool 'mabl-get_current_user' does not exist after discovery listed it.
Check ~/.copilot/logs/process-.log for the three-line sequence above for each server at child start.
Expected behavior:

A child inherits the VS Code session's MCP OAuth state for every configured HTTP server (or the host-delegated OAuth handoff succeeds), so /* and / behave the same from a child as from the parent, independent of model. If children intentionally cannot use OAuth-only HTTP servers, that should be documented so declarations can be designed around it.

Additional context:

Workaround we are using: explicit / references plus model: "claude-fable-5.1" for Atlassian; for mabl, switching the server to its documented x-api-key header auth (https://help.mabl.com/hc/en-us/articles/48563261741204) so the connection no longer depends on the OAuth handoff. Atlassian's equivalent API-token mode is not enabled for our site, so the model pin remains the only Atlassian path.
Question: is the tool definition actually attached to the model after discovery for explicit refs? Session events record the discovery result but not the per-turn tool list, so we cannot distinguish "model declined an undefined function" from "host did not bind the definition".
No credentials, tenant identifiers, or ticket content included; log lines are redacted as the host prints them.