Claude in JetBrains Copilot: The Agent IDE Now Needs an Operating Contract

If your team lives in IntelliJ IDEA, PyCharm, WebStorm, Android Studio, or another JetBrains IDE, GitHub’s June 22, 2026 Copilot update is worth treating as an operations change rather than a small plugin release. GitHub added organization and enterprise agents, queue and steering controls for Copilot CLI sessions, an Agent Debug logs summary view, Claude as an agent provider in public preview, model picker improvements, per-turn AI credits visibility, and general availability for Cloud agent in JetBrains IDEs.
The headline is not simply “Claude is now available.” The bigger shift is that GitHub Copilot for JetBrains is moving toward Copilot CLI as the default agent harness. The IDE remains the control surface, but long-running coding sessions increasingly run through a shared CLI-backed runtime that can be monitored, steered, governed, and billed consistently across surfaces. For working engineering teams, that changes the question from “which model gives the best answer?” to “which agent is allowed to change which code, under which permissions, with which logs and cost visibility?”
What Changed
The GitHub Changelog describes a bundle of agentic features for JetBrains IDEs. Administrators can publish custom agents at the organization or enterprise level and make them available directly in the Copilot Chat agent picker. Developers can send messages while a Copilot CLI request is already running: queue a follow-up, steer the current request after the active tool execution finishes, or stop the current turn and send a new message. The Agent Debug panel now has a summary view that consolidates session activity, while Cloud agent is generally available without the previous Editor Preview feature flag.
Claude as an agent provider is now in public preview for JetBrains. The setup requires installing the Claude Code CLI locally, pointing the GitHub Copilot plugin to that CLI path, and selecting Claude from the Copilot Chat agent picker. GitHub also calls out an important caveat: the Claude agent currently runs in bypass permissions mode, so file edits and tool calls are automatically approved. Business and Enterprise users also need an administrator to enable the Editor preview features policy before using it.
This follows a June 15 Microsoft for Java Developers post explaining that Copilot for JetBrains is moving to Copilot CLI as the default agent harness. The rationale is feature and model parity: maintaining a separate local JetBrains harness slows down delivery and keeps JetBrains users behind other Copilot surfaces. With Copilot CLI sessions running independently in the background, the IDE can start, monitor, and steer work without owning every runtime detail itself.
Why It Matters
First, IDE choice and agent choice are becoming less tightly coupled. JetBrains-heavy teams, especially Java, Kotlin, Android, Python, and backend groups, have often had to wait for agentic features that arrived elsewhere first. A shared CLI harness can reduce that lag and make features such as Cloud agent, organization agents, session steering, and third-party providers more consistent.
Second, agent provider choice is becoming a governance decision. GitHub’s Copilot model documentation notes that model availability depends on plan and client, and that models can be replaced or updated over time. VS Code’s third-party agent documentation makes the same strategic point from another surface: agents such as Claude and Codex can expose provider-specific capabilities while still being managed through a unified Copilot subscription and organization policy. JetBrains support brings that same multi-provider reality to teams that do not want to standardize on VS Code.
Third, the control loop for long-running agents is getting more explicit. GitHub’s Copilot CLI docs describe steering as a way to guide an agent while it is working, including interrupting a bad direction, providing feedback during a tool permission flow, or refining scope mid-task. JetBrains now exposes queue, steer, and stop-and-send choices inside the IDE. That is a practical improvement for refactors, migrations, test repair, and code review tasks where waiting for a full turn to finish can waste time and produce larger unwanted diffs.
Community Signal
The practitioner signal around JetBrains Copilot updates is less about model leaderboard debates and more about reliability, session control, billing visibility, and debugability. A recent r/JetBrains update thread highlighted Copilot CLI sessions, MCP configuration, BYOK, agent customizations, an Agent Debug panel, unified sessions, thinking effort configuration, and usage-based billing UX. That community source should not be treated as proof of product behavior, but it does show what JetBrains users are watching: whether agent features feel operationally stable inside their daily IDE.
That matters because agent rollout touches more than prompts. It touches terminal access, shell configuration, local package managers, monorepo indexing, Gradle and Maven tasks, Android tooling, corporate proxies, audit expectations, and cost monitoring. A plugin release can therefore become an engineering enablement project.
The New Operating Contract
| Area | What changed | Question teams should answer |
|---|---|---|
| Agent provider | Claude provider is available in JetBrains public preview. | Which tasks may use Claude, default Copilot agents, or Cloud agent? |
| Execution harness | Copilot CLI is becoming the default JetBrains agent harness. | How are CLI versions, shells, auth, PATH, proxies, and logs standardized? |
| Permissions | GitHub says the Claude preview currently runs in bypass permissions mode. | Where are automatic edits and tool calls acceptable, and where are they blocked? |
| Debugging | Agent Debug gets a session summary view. | Who reviews failed sessions, and how long should logs be retained? |
| Cost | Per-turn AI credits are visible in local, CLI, and Claude sessions. | When are larger contexts or higher reasoning allowed, and who monitors spend? |
The bypass-permissions caveat deserves special attention. Automatic file edits and tool calls may be fine in an isolated worktree or disposable sandbox, but they are a poor default for sensitive repositories, production branches, or regulated codebases. Treat preview agents the way you would treat a new CI runner with write access: useful, but only after scoping and audit boundaries are clear.
A Practical Rollout Checklist
• Run a narrow pilot: one team, one or two repositories, and a short sprint window.
• Separate providers in the evaluation: compare default Copilot, Cloud agent, and Claude provider on different task classes.
• Write the permissions policy first: define where bypass-style execution is allowed and where it is prohibited.
• Standardize the local runtime: Copilot CLI, Claude Code CLI, shell, Node, Python, JDK, proxy, and credential setup should be reproducible.
• Measure outcomes, not vibes: review PR quality, test pass rate, review churn, rollback rate, log clarity, and AI credit consumption.
What Developers Can Do Now
Individual developers should update the GitHub Copilot plugin, start a Copilot CLI-backed session from the IDE, and deliberately test the new control flow on a low-risk task. Try queueing a follow-up, steering the agent mid-run, and stopping a turn before it produces a larger diff. If you enable Claude provider preview, begin with a sample repository and observe exactly what it edits or invokes without additional approvals.
Team leads should create an agent operating contract before broad rollout. Classify tasks such as test generation, docs updates, refactors, migration drafts, bug triage, and PR review. For each class, decide the allowed providers, permission mode, expected human review, log retention, and cost threshold. JetBrains familiarity should not hide the fact that the execution plane now includes a CLI harness and provider-specific agent behavior.
Risks and Counterarguments
It is too early to make a preview provider the default for critical work. The permissions model may change, model availability can vary by plan and client, and multi-provider workflows can increase review burden if the team lacks a clear merge standard. There is also a risk of treating per-turn credit indicators as a complete cost control mechanism when they are only one part of a broader FinOps process.
Still, the direction is clear. Coding assistants are moving from autocomplete, to chat, to long-running agent sessions, and now to governed multi-provider systems with logs, policies, and cost visibility. The JetBrains update shows that this transition is no longer a VS Code-only story. Teams can keep their IDEs. They need to upgrade their operating model.
Sources
- GitHub Changelog: New features and Claude as agent provider preview in JetBrains IDEs
- Microsoft for Java Developers: Copilot for JetBrains is moving to Copilot CLI as the default agent harness
- GitHub Docs: Steering agents in GitHub Copilot CLI
- GitHub Docs: Supported AI models in GitHub Copilot
- VS Code Docs: Third-party agents in Visual Studio Code
- Reddit r/JetBrains: GitHub Copilot for JetBrains - June Updates