Describe the feature or problem you'd like to solve
Open sourcing all of copilot cli, and whatever else you please.
Proposed solution
Hey,
Let me preface this in the context of a developer working at a large company, writing a workflow/pipline sdk for agents, deployed on our own metal.
The reason that i/we (we as in everyone) would want copilot cli to be open sourced is due to seeing what happens internally, the raw tool execution loop, and whatever else added.
It is a blackbox for devs, and since copilot cli has very frequent releases, we are at the whims of whatever on earth is implemented in between these releases, in which we are told are x and y, but z could be included within here, changing behaviour that is unseen.
This is why it is less favourable for me to use copilot sdk for my implementation, rather pi instead.
Don't get me wrong, the features built into copilot and the sdk are desirable, hence my reason for writing this, but it is such a large "if" for whatever is pushed there, which is blackboxed.
For all we know, on each release, anything can be added or removed to the system prompt, changing behaviour, yes the sdk allows you to remove sections of this prompt, but that in itself is blackboxed, where we only know that these "sections" are changed in some way.
Why you should?
- For the above stated reasons of clarity and trust, no serious developer will implement copilot cli in headless agent workflows, due to a total blackbox
- You people added BYOK; so what reason is there to even close source this? There is no revenue loss from open sourcing this.
- A lot of major ai projects like codex, pi, hermes, and a shit ton more are open source, Though yes anthropic is closed source for claude code, we all had a view of there horrible harness engineering, which was seemingly a joke.
- More ideas/issues from others that are diagnosed further. Less time spent on strain to debug/fix issues. Even if this is closed contribution there are these benefits
- It's embarrasing to close source a cli tool in 2026
- YOU 🫵 (the copilot devs) can make a change from doing things in microslop fashion, to be more developer centric, despite the move of github going into the AI organisation. I know there are great developers working on this, just open source it!
duplicate of #83 i know, though it should be brought up again in the current climate, and after the move to byok, which is large imo for a reason to open source this.
Example prompts or workflows
No response
Additional context
No response
Describe the feature or problem you'd like to solve
Open sourcing all of copilot cli, and whatever else you please.
Proposed solution
Hey,
Let me preface this in the context of a developer working at a large company, writing a workflow/pipline sdk for agents, deployed on our own metal.
The reason that i/we (we as in everyone) would want copilot cli to be open sourced is due to seeing what happens internally, the raw tool execution loop, and whatever else added.
It is a blackbox for devs, and since copilot cli has very frequent releases, we are at the whims of whatever on earth is implemented in between these releases, in which we are told are x and y, but z could be included within here, changing behaviour that is unseen.
This is why it is less favourable for me to use copilot sdk for my implementation, rather pi instead.
Don't get me wrong, the features built into copilot and the sdk are desirable, hence my reason for writing this, but it is such a large "if" for whatever is pushed there, which is blackboxed.
For all we know, on each release, anything can be added or removed to the system prompt, changing behaviour, yes the sdk allows you to remove sections of this prompt, but that in itself is blackboxed, where we only know that these "sections" are changed in some way.
Why you should?
duplicate of #83 i know, though it should be brought up again in the current climate, and after the move to byok, which is large imo for a reason to open source this.
Example prompts or workflows
No response
Additional context
No response