Repository navigation
Copilot reports T3 pull request tools missing and only uses the terminal fallback after a follow-up #22806
Description
What happened
In the Windows T3 Code desktop app, a GitHub Copilot thread using model Auto created a PR but reported that link_pull_request and list_thread_pull_requests were unavailable, leaving the PR unlinked. After the user asked why, the agent used T3’s terminal fallback successfully.
Diagnosis
The saved turn items contain a direct call to t3-code.list_thread_pull_requests with empty input. It failed with:
Tool 'list_thread_pull_requests' does not exist.
The available records do not show a direct link_pull_request attempt.
Four minutes later, the same thread invoked acp-mcp-call through the terminal. Both tools succeeded. The stored thread pullRequests array now contains the linked PR.
Current main source documents ACP agents accepting an injected MCP server without exposing its tools, and instructs agents to use the terminal fallback. The observed failure is consistent with that documented mode, but the exact registration or dispatch cause is unconfirmed. The agent did not use the working fallback until the user challenged its initial conclusion.
Source references are to current main:
An exact-release checkout was unavailable because terminal network access was blocked and the installed application resources were inaccessible. No deterministic fresh-session reproduction was established.
Steps to reproduce
Observed sequence, not a verified deterministic reproduction:
- Start a GitHub Copilot ACP Registry thread in the Windows desktop app with model Auto.
- Ask the agent to create a PR and connect it to the current thread.
- The agent attempts
t3-code.list_thread_pull_requests, receives the missing-tool error, and reports that it cannot link the PR. - Ask why the tools are unavailable.
- The agent invokes T3’s terminal fallback, successfully links the PR, and verifies it with
list_thread_pull_requests.
Expected: The direct tools work, or the agent tries the supported fallback before reporting that linking is unavailable.
Version
0.1.1-nightly.20261018.3302. The local server environment endpoint and incident-time client traces report this version.
Triage CLI version: 0.1.0, launched with npx t3 triage.
Environment
Windows x64 10.0.26300; T3 Code Nightly desktop app with local server; Node v26.8.2 in the triage environment; provider acpRegistry_copilot; selected model auto.
Copilot CLI version and Auto’s resolved model are unknown.
Evidence
2026-10-20T11:44:12.550Z
dynamic_tool t3-code.list_thread_pull_requests
input: {}
status: failed
output: {"message":"Tool 'list_thread_pull_requests' does not exist.","code":"failure"}
2026-10-20T11:44:17.096Z
Assistant reports both PR tools unavailable and the PR unlinked.
2026-10-20T11:48:54.841Z
Server MCP tools/call link_pull_request: Success
2026-10-20T11:48:54.979Z
Server MCP tools/call list_thread_pull_requests: Success
Fallback results:
isError: false
link result alreadyLinked: false
list result includes the PR
Related issues
#18635 discusses missing T3 tools under Claude enterprise MCP policy. This report concerns Copilot ACP; no enterprise-policy rejection was established.
No confirmed duplicate or shipped fix was identified in the accessible search results and release notes.
Fix applied or workaround
The affected agent already ran the following pattern inside its own thread environment, first with link_pull_request and a PR URL, then with list_thread_pull_requests and empty input:
$env:ELECTRON_RUN_AS_NODE = '1'
& $env:T3_ACP_MCP_NODE $env:T3_ACP_MCP_ENTRYPOINT acp-mcp-call <tool> <json>The existing workaround succeeded. Triage made no configuration, source, or database changes.
Filed by
Prepared by Codex, based on GPT-6, via t3 triage. Exact model identifier unavailable.
Activity
juliusmarminge commentedon Oct 21, 2026
T3 registers the PR toolkit globally and the Copilot (ACP) adapter supplies the MCP server eagerly at session start, but it only advertises the server descriptor; it does not confirm the model-visible tool list the way the Codex and Claude adapters wait for registration. A later terminal success does not establish lazy attachment on its own. Could you share the Copilot CLI version and the tool list the agent reports on the first turn? If a registration race is confirmed, the smallest candidate is waiting for Copilot tool readiness before the first prompt. We could not run Copilot here.
daniellindem commentedon Oct 21, 2026
Thanks for looking into this. Answers below, from inside the affected thread:
Copilot CLI version:
GitHub Copilot CLI 1.0.101(fromcopilot --version).Model: Auto resolved to
claude-sonnet-5.5. The server reportsinheritedModel: "auto", so that is the selected model, not the resolved one.Tool list on the first turn: No
t3-codetools were in the function list. That coverslink_pull_request,list_thread_pull_requests,orchestrator_capabilities,delegate_taskandpreview_*. Only Copilot CLI's built-in tools were present:powershell,read_powershell,view,edit,create,grep,globtask,sql,skill,web_search,web_fetchgithub-mcp-server-*,*_agent,run_dynamic_workflow,dynamic_workflows_manageEvidence for a registration race rather than a server-side failure:
T3_ACP_MCP_ENDPOINT,T3_ACP_MCP_AUTHORIZATION,T3_ACP_MCP_NODEandT3_ACP_MCP_ENTRYPOINTwere all set in the terminal environment. The server had handed the MCP server to the session.acp-mcp-call:link_pull_request,list_thread_pull_requests, and laterorchestrator_capabilities. So the server worked the whole time. Only the model-visible tool list was missing the tools.Caveats:
Tool 'list_thread_pull_requests' does not existerror came from my own attempt to call it as a regular tool, which the harness rejected.This is consistent with your suggestion: waiting for Copilot tool readiness before the first prompt would probably avoid it.
ianrowe12 commentedon Oct 28, 2026
Here is the first-turn tool list you asked for, from a direct probe of Copilot CLI 1.0.105 on macOS (darwin arm64). The probe ran outside T3 and used a stub MCP server that logs every request. In each run the client sent
initialize, thensession/new. The no-prompt runs then watched for 60 s; the prompt runs waited 20 s, sent one prompt, and watched 20 s after the turn.initializeadvertisedmcpCapabilities: {http: true, sse: true}.{name, command, args, env}insession/newmcpServers(the shape T3 sends fort3 acp-mcp-bridge){type: "http", name, url, headers}insession/newmcpServersserver/discover,initialize,notifications/initializedandtools/listwithin about 0.2 s ofsession/new. TheAuthorizationheader was present on each request.c7probe-probe_echoalongside the built-in tools.--additional-mcp-configlaunch flaginitializeandtools/list, within about 0.1 s.The tool lists are the model's own answers, so they aren't an exact inventory. The HTTP-run answer also left out
list_agents,read_agentandwrite_agent. Still, input tokens for the turn were 18,026 for the stdio run and 18,069 for the HTTP run, which fits one extra tool definition. Neither turn made a tool call.These results suggest the problem depends on the transport in 1.0.105: Copilot's ACP agent accepts HTTP MCP servers from
session/newbut doesn't start stdio ones. They don't rule out a race in the reporter's setup, which was Windows on 1.0.101.acpMcpContextinpackages/provider-acp/src/server/adapter.tsalways sends the stdio bridge, because codex-acp 1.2.0 and pi-acp drop injected HTTP servers. A candidate fix, limited to Copilot, is for the Copilot ACP Registry flavor to send T3's HTTP endpoint and Authorization header instead. Other agents would keep the bridge. A fix would also need to coversession/loadand the eager activation path, not justsession/new. I haven't probedsession/loadwith an HTTP entry yet. If this direction sounds right, I can check that, then open a small PR.— Opus 5.5 with Claude Code, reviewed by GPT 6.1 Sol