I pointed GitHub Copilot CLI at a real calendar bug, and it fixed it.
GitHub Copilot CLI fixed a real bug in my calendar app, but it made me work for it. I tested it in a September 2025 first look, right after GitHub released it in public preview, on production code instead of a demo app.
The business case
GitHub had just dropped a terminal tool built to compete with Claude Code, which I called the undisputed king of this space at the time. If you build software for a living, the useful test is whether a new tool can do real work on the code you already ship. I'm not interested in watching these tools build demo apps.
I gave GitHub Copilot CLI a real bug and shared my raw takes as I went. I held the full Claude comparison for a later video. The question I had was whether a new terminal agent earns a spot in a builder's day, and what gets in the way.
Install speed wasn't the hard part. Permission prompts, seeing what changed, and starting in the right folder decide whether you keep using it. Copilot CLI has changed a lot since September 2025, so treat the details below as a dated first look and check GitHub's current Copilot CLI docs before you rely on them.
A brand-new preview
When I recorded, the tool was in public preview and there wasn't much information about it. The GitHub issues list was filling up fast. I counted about 22 issues the first time I looked and about 36 by the time I recorded.
One detail stood out. At the time, Windows support was marked experimental, which I found fascinating coming from Microsoft, the company that makes Windows. Also, don't confuse this tool with the older Copilot CLI from about three years earlier. I thought that one was being deprecated, but the name itself isn't new.
Install and sign in
Setup was quick. You install it with npm (GitHub's install guide), then type copilot in the terminal. On camera I said you need a paid GitHub account for it to work, so check the Copilot plans page for what's required today.
The first screen asked permission to read files. It looked a lot like Claude, maybe simpler, because it only had the basics. Slash commands handled login and logout with autocomplete, and sign-in was the standard browser flow with a code. There was no tab completion, so I used its change-working-directory command to point it at my project.
The real bug
The test was a calendar system I was building, where the items on the calendar are jobs. When you drag a job to a new spot, a "select time" modal is supposed to let you pick the time and save it. It didn't. The modal wasn't running the same update logic as the rest of the calendar, so I asked Copilot CLI to fix that.
Jump to
- 0:00 Introduction to GitHub Copilot CLI
- 0:39 Exploring the GitHub Copilot CLI
- 1:23 Installation and Setup
- 2:09 Running on a Real Project
- 3:32 Troubleshooting & Observations
- 6:55 Final Thoughts & Comparison
- 9:07 Conclusion & Call to Action
I walk through the install, the stuck run and the fix on screen in the full video on my channel: GitHub Copilot CLI first look on YouTube.
Where I got stuck
The first run went off the rails. It asked to access paths outside my project and started looking through my whole folder, outside the calendar project. I said no, exited and started over.
That one was on me. You have to cd into the project folder before you launch copilot. I thought I could set the path from inside the prompt box, but it's a plain text box.
On the second run I passed the allow-all-tools flag. It still asked me for permissions, asked whether to add directories to an allowed list, and kept saying a parent directory didn't exist. I understand why a tool asks before it touches your code. In practice the constant prompts were annoying.
What it got right
After one follow-up prompt, where I told it I saw no API calls in the network tab when I dragged a job in month view, I checked a job on the 23rd, went back to the view, and the fix had worked. It did a pretty good job, and I could trace along the code as it worked.
I liked the formatting more than what I'd been getting from Claude, which was a little off for me. The output had nice emojis, and it called out the functions it was calling so I had some visibility. In that September 2025 build it ran by default on Claude Sonnet 4. You could switch to GPT-5 with an environment variable set before launching. GitHub keeps the current list on its supported models page.
Terminal versus the IDE
My biggest gap was feedback. In VS Code I see the files changing in a side panel, skim the changes as they happen, and choose what to keep or revert. That's how I work. In the CLI preview I tested, I could see that a file changed, but not what changed in it.
For me that was a disadvantage. If you live in the command line, it may not bother you at all, and any terminal tool gives up some of that visibility.
Test it on real code
Overall it was a pleasant experience, and I was excited about it as an early preview. The point of a first look like this is to put a new AI coding tool on the code you actually ship and see where it helps and where it slows you down. I have a related run with GitHub Spec Kit on a large Nuxt 2 app and a post on keeping engineering judgment in vibe coding.
If you're deciding which AI coding tools belong in your workflow and want a second set of eyes on it, that's what I cover in a 1:1 strategy call.
About Dwain
I'm Dwain Browne, Founder of LeadScore AI and SnapSuite. I'm a Toronto-based software architect with 25+ years across software, sales, operations and entrepreneurship. SnapSuite helps contractors and trades teams get paid faster, and LeadScore AI shows you which leads deserve your next call. I also run Vibe Code to Profit, a community helping people build software with AI.