Update GitHub Copilot to Copilot CLI

[devm33]

Updates GitHub Copilot ACP registry entry to use @github/copilot

[nickzhums]

Hi @devm33, I do worry that putting both entries on the registry could be confusing from a user perspective. I'd also strongly suggest we only use customer-facing names rather than package details.

For example, we should surface GitHub Copilot (rather than GitHub Copilot Language Server, which is really just an underlying implementation detail) and GitHub Copilot CLI.

Thanks :)

[devm33]

@nickzhums update the PR here per our latest discussion!

[formulahendry]

@devm33 Let me check with the team to see how to make it work for both main and jetbrains acp registry. Stay tuned. 😄

[formulahendry]

As aligned with @devm33 , we'd like to make below changes:

• registry.json: using CLI npm, only one entry is shown
• registry-for-jetbrains.json: using CLS npm, only one entry is shown
• For naming: both use GitHub Copilot

Based on above requirements, I have drafted a PR in my forked repo: formulahendry#2

Note: for id field of two pacakges in agent.json‎, in case IDE clients would use the id field as unique identifier, I use github-copilot-cli for CLI, while keep no change for CLS to avoild any potential breaking changes.

Tested with build_registry.py:

PS C:\code\acp-registry> $env:SKIP_URL_VALIDATION="1"; uv run --with jsonschema .github/workflows/build_registry.py
Added agent: auggie v0.16.1
Added agent: claude-code-acp v0.16.1
Added agent: codebuddy-code v2.50.3
Added agent: codex-acp v0.9.2
Added agent: corust-agent v0.3.1
Added agent: factory-droid v0.57.14
Added agent: gemini v0.28.2
Added agent: github-copilot v1.430.0
Added agent: github-copilot-cli v0.0.410
Added agent: junie-acp v744.2.0
Added agent: kimi v1.12.0
Added agent: mistral-vibe v2.1.0
Added agent: opencode v1.1.65
Added agent: qoder v0.1.28
Added agent: qwen-code v0.10.1
Added agent: stakpak v0.3.41

Built dist/ with 16 total agents
  registry.json: 15 agents (excluded: github-copilot)
  registry-for-jetbrains.json: 12 agents (excluded: claude-code-acp, codex-acp, github-copilot-cli, junie-acp)

@ignatov @devm33 Please help have a look to see if it is good to go. cc @nickzhums
Feel free to use my PR or create a new one per your convenience. 😃

[devm33]

thanks @formulahendry!

[ignatov]

Thanks, the intention is clear, I'll take a look soon.

[anna239]

@formulahendry could you please elaborate why do you want to use different npm packages for different editors? If you need to support some custom scenarios for different IDEs they can either be exposed via capabilities or you can rely on the client info, for example in IntelliJ it would be

{"name":"JetBrains.IntelliJ IDEA","version":"2025.3.2","title":"IntelliJ IDEA 2025.3.2"}

and it'll be included in initialization request

[formulahendry]

@anna239
The CLS will have some native support optimized for JetBrains IDEs, and will also use CLI as underlying Agent Harness. This is already aligned with @devm33 .

From user perspective, by using CLS npm, JetBrains IDEs users would not only get CLI features as agent loop, but also get some native support optimized for JetBrains IDEs.
From tech perspective, the software development life cycle of CLS npm will go smoothly with its own plan/release schedule, leveraing CLI as Agent Harness, optimized for JetBrains IDEs users.

One similar example would be:
As a web develpoer, may have two choices to use JetBrains IDEs:

• Use WebStorm
• Use Intellij + Install and config several Intellij plugins for web development

From user perspective, I think most web develpoers would choose WebStorm, for the out-of-box optimized experience.
From tech perspective, the software development life cycle of WebStorm will go smoothly with its own plan/release schedule, leveraing the infra and component of Intellij platform, optimized for web development.

Hope it could help explain the why part.

[anna239]

@formulahendry thank you for the explanation, I have a following concern: we plan a better support for custom ACP registries for enterprise user: f.i. a company can limit a list of available agents for their developers based on compliance/security/... In this case we will suggest creating their own registry based on this one with some agents filtered out/versions frozen.
I'm afraid that in this case it might be confusing, that they have to use registry-for-jetbrains and not registry, I think some people will just mix them up and get a wrong Copilot version in the end.
A possible solution might be to have some other npm package that would depend on both copilot-language-server and copilot and would route the request to the correct package based on the client info?

[formulahendry]

A little off-topic: For custom ACP registries for enterprise user, I would recommend to take a look how MCP Registry does:
https://github.com/modelcontextprotocol/registry/blob/main/docs/design/ecosystem-vision.md
Subregistries might maintain its own data source.

@anna239 Back to this topic, I think we would not like to introduce a third npm package in short/medium term:

• From user perspective, user may find one more npm package through search engine/npm registry..
• From tech perspective, it may increase maintenance cost

The balance those, we'd keep current design mentioned in #26 (comment)

[anna239]

@formulahendry we've discussed one more time with the team and I think we need to find other solution for providing several packages then adding it to JetBrains-only registry. Originally JetBrains-only registry was created because we had some agents integrated differently for legacy reasons and we wanted to exclude them not to confuse the users. After we move those agents to the ACP, we might get rid of JetBrains-only registry altogether.
One of the solutions for your case can be adding some compatibility flags to the registry format so that clients can decide which file to use, what would you say about this approach?

[formulahendry]

Hi @anna239 , thanks for sharing detailed context!
For adding some compatibility flags to the registry format so that clients can decide which file to use, do you mean something like below?

{
  "id": "github-copilot",
  "name": "GitHub Copilot",
  "version": "xxx",
  "description": "GitHub's AI pair programmer",
  "repository": "https://github.com/github/copilot-language-server-release",
  "authors": [
    "Microsoft"
  ],
  "license": "proprietary",
  "distribution": {
    "npx": [
      {
        "package": "@github/copilot-language-server@1.430.0",
        "args": ["--acp"],
        "clients": ["jetbrains"]
      },
      {
        "package": "@github/copilot@0.0.367",
        "args": ["--acp"]
      }
    ]
  }
}

With above agent.json, JetBrains will pick CLS to install, while other IDEs will pick CLS to install.

[anna239]

@formulahendry yes, I mean something like this but I think the flag should express some difference between the clients, as there can be other client with similar to JetBrain's capabilities, it should also be able to pick the right package. For instance, if copilot-language-server in fact requires syntax-highlighting feature (just an example), then it should be
"requirements": ["syntax_highlighting"]

[nickzhums]

Hi @anna239 , I feel the discussion is becoming a bit out of scope for this original PR, should we discuss this in a separate issue instead? We can adapt to the new format later if needed.
If @formulahendry 's original proposal is ok for the time being, is it ok to merge it first?

[ignatov]

@nickzhums The original proposal is not OK, we can either keep two copilots for a while or decide how to handle client capabilities and come back to it later. Treat that list like a list of apps in the marketplace, we have to upload both versions and filter them or to have a single version and adapt its behavior on the fly

Having a dedicated file for JetBrains IDEs was a hack, and we’re planning to remove it once we share common wrappers for Claude and Codex. The GitHub approach proposed by @formulahendry will likely stay for now, but I’d be glad to avoid relying on GitHub long-term.

Moreover, it looks like we’ll soon move away from GitHub and host this as a proper web service, essentially a marketplace of agents, where client capabilities will be more than welcome