Run GitHub Copilot through the Copilot SDK instead of ACP

[Radu028]

GitHub Copilot works in T3 today through the ACP Registry provider (see #15733). I use it every day (Copilot CLI 1.0.105, Windows), and five gaps come from ACP itself, not from T3's ACP adapter, so they can't be fixed while Copilot stays on ACP:

1. Steering. Copilot's ACP session/prompt aborts the session, which cancels running background subagents (ACP: session/prompt unconditionally aborts the session, cancelling all running background sub-agents (interactive TUI does not) github/copilot-cli#4555, reproduced on 1.0.105 without any session/cancel). fix(server): queue Copilot follow-ups without killing background agents #26715 now queues follow-ups so the work survives, but a real steer is not possible over ACP. The SDK's session.send({ mode: "immediate" }) injects a message into the current turn without aborting it.
2. System prompt. Over ACP, T3's instructions can only travel in user messages, so Copilot's own compaction drops them. One real compaction removed 108 of 116 messages, including the first prompt with T3's instructions. Copilot also never sends an ACP compaction_update, so T3 has to read its raw event feed to notice (fix(acp): agents get T3's runtime notes once per session, not on every message #26959). Copilot's default prompt also limits answers to 100 words, and nothing in ACP can change that: passing the SDK's systemMessage customization through session/new _meta has no effect, which I checked in the resulting system prompt. The SDK accepts systemMessage (append, replace, or per-section customize, for example removing the tone section), the equivalent of Claude's system prompt append and Codex's developer instructions.
3. MCP transport. Copilot rejects stdio MCP servers over ACP, so threads never get T3's tools (Copilot reports T3 pull request tools missing and only uses the terminal fallback after a follow-up #22806; HTTP fix in fix(acp): Copilot threads get T3's tools #26968). The SDK accepts both stdio and HTTP servers.
4. Usage. Copilot sends no token or billing data over ACP, so Copilot threads never show up in Usage. The SDK emits assistant.usage events with token counts and billing information that Usage could read.
5. Tool fidelity. Over ACP, tool calls arrive with coarse kinds, so T3 shows subagent tools as generic "Tool" rows, grep and glob as "Read", and commands without exit codes. The SDK's tool.execution_* events carry the real tool name, arguments and structured results, including shell exit codes.

GitHub's own VS Code integration runs Copilot through the SDK (copilot-runtime --headless --stdio), not ACP.

Many developers can only use Copilot at work. For them, these gaps decide whether T3 is usable at all.

Would you accept a dedicated Copilot driver built on @github/copilot-sdk (MIT) against the orchestration v2 adapter interface? If so, I can open it and keep it focused. If you prefer to keep Copilot on ACP, these are the gaps users will keep hitting.

@juliusmarminge

[t3dotgg]

Note

🤖 Claude Opus 5.5 responding on behalf of Theo

Closing: there is ACP support, use that. Copilot already runs through the ACP registry.