GitHub Is Moving JetBrains Copilot Onto Copilot CLI Because the Harness Is Now the Product
The most important line in Microsoft’s JetBrains Copilot announcement is not the word “JetBrains.” It is “harness.” GitHub is moving Copilot for JetBrains onto Copilot CLI as the default agent harness, and that tells you where the coding-agent market has landed: the runtime around the model is now the product boundary.
That sounds like plumbing. It is not. The harness decides how a coding agent stores session state, exposes tools, asks for approvals, reads instructions, connects to MCP servers, manages worktrees, summarizes history, routes models, and reports spend. If the model is the engine, the harness is the car, the dashboard, the brakes, and the maintenance log. Developers notice the engine first. Teams eventually buy the whole vehicle.
Microsoft’s post says GitHub Copilot for JetBrains is gradually making Copilot CLI the default agent harness, while the current local JetBrains harness will be deprecated later. The practical architecture is simple: Copilot CLI sessions run independently in the background on the developer’s machine, while the JetBrains IDE starts, monitors, and steers those sessions. Microsoft describes this as the same architecture used across GitHub Copilot today.
That last sentence is the strategy. GitHub does not want one agent brain in VS Code, another in JetBrains, another in the terminal, and another in the desktop app. It wants one common execution layer that every surface can call. That is how Copilot features ship faster, how bugs get fixed once, and how enterprise controls become enforceable instead of decorative.
Session migration is useful. It is also a lossy handoff.
Existing local JetBrains sessions are not supposed to disappear in the transition. GitHub’s migration guide gives users three commands: /migrate, /migrate:workspace, and /migrate:worktree. The key implementation detail is that Copilot does not transplant the old session byte-for-byte. It summarizes the local session’s chat history and starts a new Copilot CLI session with that summary attached. The summary is visible as local-session-history.md.
That is the right kind of pragmatic migration. It is also exactly where engineering teams should slow down. A summary is not a transcript. It can drop failed attempts, omit a constraint the user added three turns ago, flatten tool-output nuance, or preserve sensitive context that should not move into a new session. A human handoff note is useful because someone reads it. An agent handoff note should get the same treatment.
Before migrating serious work, JetBrains users should inspect local-session-history.md, confirm the repo state, and ask the new session to restate its assumptions. If the task touches auth, billing, deployment, data migration, or anything with customer impact, do not let a summarized chat history become the only source of truth. Checkpoint the branch. Save the plan. Keep the tests outside the transcript.
Why GitHub wants one harness
The upside for JetBrains developers is obvious. If Copilot CLI is where GitHub ships agent features first, JetBrains users do not want to be trapped behind a bespoke local harness. A shared harness means shared model routing, shared MCP behavior, shared slash commands, shared approval semantics, shared worktree handling, and fewer “this works in the CLI but not in IntelliJ” bugs.
That parity matters more for agents than it ever did for autocomplete. Autocomplete is mostly stateless. Agent work is stateful by design. A team can tolerate slightly different completion behavior between editors. It cannot reasonably maintain four different operating manuals for how an agent creates branches, invokes tools, handles hooks, applies instructions, summarizes context, and spends AI credits.
The current feedback issues around the JetBrains rollout show why this consolidation is necessary. Developers are reporting login failures in PyCharm and CLion, “Copilot is still initializing” states, instruction files not being respected, missing slash commands, hook semantics that do not behave as expected, and repeated warnings after crossing 50.1% of included AI credits. Those are not model-quality complaints. They are runtime complaints. They are exactly the category a common harness is supposed to make less random.
There is a cost angle hiding here too. When JetBrains sessions behave more like Copilot CLI sessions, they also participate more directly in the same usage model. Copilot’s AI Credits now cover chat, agent mode, code review, cloud agent, CLI, Apps, and related agentic surfaces. A shared harness can make usage reporting more consistent, but it can also make more IDE workflows capable of spending from the same budget pool. Admins should test that before the rollout becomes ambient.
The practitioner checklist is boring, which is why it matters
If your team uses JetBrains and Copilot, do not treat this as a cosmetic backend change. Pilot it like an agent-platform migration. Start with non-critical repositories. Migrate a few real sessions and inspect the generated summary file. Compare /migrate:workspace and /migrate:worktree behavior. Test whether project instructions are respected. Exercise MCP servers, hooks, authentication, slash commands, and diff review. Confirm which admin policies must be enabled for Copilot CLI and preview features.
Also document the escape hatch. Can a developer start fresh without carrying old context forward? Can they roll back if a config format changes? Can they tell whether a session is running locally, in a worktree, or via another Copilot surface? These questions sound operational because they are. Agentic development is software operations with a chat box attached.
The bigger market signal is that GitHub and OpenAI are converging from opposite directions. OpenAI is making Codex import Claude Code setup because workspace portability is now a competitive feature. GitHub is moving JetBrains onto Copilot CLI because runtime consolidation is now a product strategy. Both moves say the same thing: the agent is not just the model. It is the accumulated working environment around the model.
That is good for serious users if vendors make the harness observable and governable. It is bad if “unified harness” becomes a polite way to hide more spending, more state, and more permissions behind one brand. The winners in this category will not merely answer prompts well. They will make session state inspectable, migrations reviewable, tool access legible, and usage predictable across every surface where developers actually work.
Sources: Microsoft DevBlogs, GitHub migration guide, GitHub Copilot CLI releases, Copilot IntelliJ feedback issues