GitHub Copilot as an opt-in provider on the official Copilot SDK

[NK-Works]

Summary

This discussion asks for a direction decision. Should T3 Code have an opt-in GitHub Copilot provider built on @github/copilot-sdk?

CONTRIBUTING.md says a new provider needs maintainer approval before code. #32221 was closed for that reason, and the closing comment asked for an Ideas discussion. This is that discussion. A clear yes or no is useful either way.

Why Copilot

Many developers get Copilot through their employer's Microsoft or GitHub AI plan. That plan includes a large monthly allowance of premium requests, and a lot of it goes unused.

T3 Code can run several agents in one place. A team could have Claude plan the work and hand parts of it to Copilot agents. That uses Copilot credits the company already pays for and reduces spend on other providers. The Copilot CLI alone does not support this kind of workflow.

#15733 has 11 upvotes, and at least one team evaluating T3 Code said native Copilot support would help them adopt it.

Why ACP is not enough

Copilot runs through the ACP Registry today, and basic turns work. The problems below come from what ACP can express. They were re-checked on current main after #26951, #26651, #26968 and #26959 landed.

1. Steering. AcpProviderCapabilitiesV2 has supportsActiveSteering: false, so T3 Code steers by interrupting and restarting the turn. That cancels running background agents. Upstream closed ACP: session/prompt unconditionally aborts the session, cancelling all running background sub-agents (interactive TUI does not) github/copilot-cli#4555 and treats holding session/prompt as intended, so ACP will not fix this. [Bug]: Steering a GitHub Copilot thread kills its running background agents #26695 and [Bug]: Copilot ACP runs stay Working while a background (async) shell runs, because session/prompt is held #27301 are both caused by it.
2. System prompt. ACP has no channel for T3 Code's instructions, and Copilot drops them when it compacts. The SDK has a systemMessage option, which works like Claude's system prompt append and Codex's developer instructions.
3. Fork and rewind. ACP has canForkFromTurn: false. T3 Code falls back to a context handoff, but the Copilot session still keeps the context the user removed.
4. Adapter boundaries. The shared ACP adapter already has Copilot-specific code in copilotAcp.ts, an agent-id gated github.com/copilot/sessionEvent feed, and branches in adapter.ts. docs/internals/adding-a-provider.md says "Never add agent-id checks to the generic registry adapter." A separate package moves that code out of the shared adapter.

Proposal

• Add a provider package, for example packages/provider-copilot, on @github/copilot-sdk. It is off by default and uses the user's installed copilot CLI and copilot login.
• Keep the Copilot ACP Registry entry unchanged.
• Ship it in small PRs. Steering and system prompt go first, then fork and rewind, then text generation.
• Contributors will maintain the package and keep it inside the documented provider boundaries.

If the maintainers already plan their own Copilot provider work, say so here, and the gap analysis above can go into that work.

Reference implementation

#32221, with #32630 for Windows, is a working implementation. Contributors tested it with real Copilot accounts.

• Rewind removed the discarded turn from Copilot's own session file.
• Steering worked during a running command and during a background agent.
• Approvals with decline feedback, questions, and plan with Implement worked.
• Text generation for titles, commits and branches worked with Copilot as the only configured provider. Support Copilot as a text generation provider #31680 asks for the same thing.
• Stop and steer for Claude threads still worked after the change.

The PR is linked as evidence only. It does not need to be reopened.

History

Item	Type	Result
#6679	Discussion: Support GitHub Copilot CLI	Closed
#7656	PR: Copilot provider via @github/copilot-sdk	Closed
#15733	Discussion: Copilot CLI as a first-class provider	Closed, "use ACP"
#26984	Discussion: Run Copilot through the SDK instead of ACP	Closed, "use ACP"
#27520	PR: Copilot threads through the SDK	Closed
#31680	Discussion: Copilot as a text generation provider	Open
#32221	PR: Copilot as an opt-in provider	Closed, no prior approval

Earlier discussions were closed with "use ACP". This one lists the specific gaps that ACP cannot close for Copilot.

Question for maintainers

Yes, no, or not now: an opt-in Copilot provider on @github/copilot-sdk, with the ACP Registry entry unchanged, shipped in small PRs.

Original proposal and gap analysis by me in #15733 and #32221. Live testing by @wSedlacek, @maria-rcks and @NicL9923.

Finally, thank you for considering :)

[wSedlacek]

Note

🤖 Composer responding on behalf of wSedlacek

Prior effort: #32221 and Windows follow-up #32630 (closed for prior-approval / no new providers without a product yes).

What we learned trying it

• ACP Registry alone is not enough for the Claude-shaped loop people expect: steer a live turn, stop one background agent, native rewind that the model actually forgets, and decline-with-reason on approvals. The SDK path can express those; ACP still could not on the main we measured against.
• Text-generation (titles/commits) with Copilot as the only configured provider is a real ask — once the provider is enabled it should show up in those pickers with no second provider required.
• Steering is easy to get wrong around subagents: resetting mainAgentBusy / steered flags on every assistant.turn_start/idle, including events that carry agentId, breaks steer gating for the main turn. Guarding on “no agentId” (or equivalent) is required; a community patch for that landed on the PR.
• Windows is a separate packaging problem: @github/copilot-sdk starts the CLI without a shell, so copilot.cmd from an npm global install never runs unless you add an explicit Windows spawn path.
• Product gate is clear from maintainers: direction decision here first; do not open another provider PR without a yes.

[DCarretero59]

+1 for GitHub Copilot as its own opt-in provider.

I've invested heavily in the native SDK integration on a T3code I've been managing for work as the original discussion mentioned, a lot of enterprises offering Copilot as their harness could benefit a lot from this kind of agentic flows and if we could get it natively through T3 that would only increase its adoption at an even wider scale.

I understand that the limitations of how it handles their credits and whatnot may differ from common harnesses, but I think the investment and value should not be taken lightly.

Some details from that build, in case they help with the maintenance question. I followed docs/internals/adding-a-provider.md (packages/provider-copilot), and it fit the documented provider boundaries without special cases.

• Package shape: ./settings, ./client, ./server and ./testing, like Pi. Server code imports only provider-core/server, contracts and shared, and reaches the server through ProviderHost.
• Instances and sign-in:
  • Off by default. Uses the user's own copilot CLI and copilot login, or a token set on the instance.
  • Inherited GH_TOKEN-style variables are dropped, so instances don't silently share an account.
  • Status checks use the SDK's auth and model calls and never open a session.
• What it supports: streaming with shell exit codes, steering the running turn, T3's instructions as a system message, T3's MCP tools, approvals with Copilot's own choices, questions, Stop, resume, and usage limits with their reset date.
• What it doesn't yet:
  • Fork, rewind, subagents, plan mode and text generation are reported as unsupported until they're built.
  • Only Supervised and Full access are offered, since those are the modes Copilot enforces natively.
• Tests: replay fixtures recorded from the real CLI for simple, multi_turn, turn_interrupt, tool_call_denied_write, message_steering and provider_thread_resume.
• Footprint: outside the package, only the registration points, fixtures and docs. The SDK's ~150 MB bundled CLI runtimes are left out, since the provider uses the user's binary.

That fits the plan above: a self-contained first PR, then rewind, subagents and text generation, with #32221 as the reference for those. Happy to help test whichever direction you choose.

[ArunTS96]

I would love to have this native support for copilot inside t3code.