← Back to news
24/09/2026

Copilot for JetBrains 1.18.0: delegate to agents without losing control

Why this JetBrains update is more than another Copilot release

GitHub Copilot for JetBrains 1.18.0 is a small-looking release with a large workflow implication: it moves agentic coding closer to the daily environment of engineers who live in IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider, CLion, DataGrip, RustRover, and the rest of the JetBrains family. The headline features are AI-assisted tool approvals, shared organization skills and instructions, plan mode for the Codex agent, and more persistent control over MCP tools. That may sound like a list of product toggles, but for a senior developer it is really about one question: how do we let coding agents do more useful work without handing them uncontrolled authority over a repository?

For the last two years, many teams have experimented with AI in two separate modes. In one mode, an assistant completes lines, answers questions, or drafts a function inside the editor. In the other, a more autonomous coding agent works in the background, opens a branch, commits changes, and eventually asks for review. The productivity ceiling is higher in the second mode, but so is the operational risk. Agents need tools. Tools can read files, run commands, call MCP servers, inspect issues, update pull requests, and sometimes touch external systems. If every tool call requires a manual click, the agent becomes slow and frustrating. If every tool call is automatically approved, the human has lost one of the most important safety levers.

This update is interesting because it attacks the problem at the permission boundary. Assisted approvals allow low-risk tool calls in Copilot agent sessions to be approved automatically while higher-risk actions still ask the developer to decide. Shared skills and organization-managed instructions push team standards into the agent context. Plan mode gives engineers a point to review the approach before code is changed. Persistent MCP controls make the tool surface more explicit. In other words, GitHub is not only trying to make Copilot write code; it is trying to make Copilot fit a governed engineering workflow.

What the tool is

GitHub Copilot for JetBrains is the official Copilot plugin for JetBrains IDEs. It brings Copilot chat, inline suggestions, and agent-oriented workflows into environments used by many backend, JVM, Python, JavaScript, mobile, data, and C++ teams. The 1.18.0 release expands the agent experience inside these IDEs. The practical value is not that JetBrains users can finally ask AI for code; they already could. The value is that the assistant is getting closer to the way senior engineers actually delegate work: define a task, provide repository context, review a plan, let the agent perform bounded implementation steps, inspect the diff, run verification, and decide whether the result deserves to move forward.

The release notes identify four capabilities that matter most for real teams. First, assisted approvals classify some tool calls as low risk so an agent does not need to interrupt you for every safe read or routine action. Second, shared skills and instructions allow organizations and enterprises to provide reusable guidance to local and agent sessions. Third, Codex plan mode lets a developer review, refine, or approve a plan before implementation starts. Fourth, MCP tool controls make it easier to switch the built-in GitHub MCP Server on or off and manage individual tools persistently.

Those features should be read together. A coding agent is only productive when it has enough context and enough permission to act. It is only safe when the permission model is visible and the human can still intervene. A senior engineer should therefore see this release less as a shiny IDE feature and more as a set of workflow primitives: context, planning, tool authority, and review.

How to install or access it

The installation path is straightforward. You need a GitHub account with access to Copilot Free for limited usage or a paid Copilot plan for full access. In a JetBrains IDE, open the Plugins settings, search the Marketplace for the GitHub Copilot plugin, install it, restart the IDE, then use the Tools menu to sign in to GitHub. GitHub documents compatibility for supported JetBrains products, including IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider, CLion, DataGrip, DataSpell, Android Studio, PhpStorm, RubyMine, RustRover, JetBrains Client, MPS, and Code With Me Guest.

For teams, the more important setup work happens after the plugin is installed. You should decide which repositories are safe for agent use, what instructions the agent must follow, which commands are allowed, which MCP servers are approved, and which tasks are appropriate to delegate. The official documentation for repository custom instructions is a good starting point. It supports repository-wide instructions, path-specific instructions, and agent instructions through files such as AGENTS.md. Those files should not be motivational fluff. They should tell the agent how the repository is built, tested, linted, packaged, and reviewed.

A useful onboarding sequence is to install the plugin in one IDE, choose a medium-sized repository with good tests, create a first instructions file, and ask the agent to perform a low-risk task such as improving a test, updating documentation, or refactoring a small internal helper. The goal of the first session is not to maximize autonomy. The goal is to learn where the agent needs clearer context, where the approval prompts appear, and which commands should be documented before broader rollout.

Concrete use cases for senior engineers

1. Test-gap closure. A senior engineer can ask the agent to inspect a module, identify important untested branches, and propose tests. With plan mode, the engineer can require the agent to explain which behaviours it will cover before implementation. The productivity gain is strongest when the repository already has deterministic test commands in its instructions. Instead of spending the first ten minutes discovering how tests run, the agent can move directly from analysis to a focused diff.

2. Dependency or framework migrations. JetBrains IDEs are common in ecosystems where migrations can involve many small edits: Java version updates, Kotlin idioms, Gradle configuration, Spring changes, Python typing improvements, or frontend API changes in WebStorm. An agent can draft the repetitive edits, but the human should review the plan for architectural impact and verify that the migration strategy is incremental. Assisted approvals help the agent move through low-risk inspection steps, while higher-risk commands still require human confirmation.

3. Pull request cleanup. Many senior developers lose time on mechanical PR feedback: rename variables, add missing tests, update docs, align formatting, or split a helper. These tasks are good candidates for agent delegation because the desired outcome is visible in the diff. The engineer still owns the merge decision, but the agent can reduce the cost of addressing review comments.

4. Repository onboarding. Copilot documentation explicitly recommends custom instructions that describe what the repository does and how to bootstrap, build, test, run, and lint it. Asking the agent to draft those instructions, then reviewing them carefully, is a practical first use case. The output becomes reusable infrastructure for every later AI session. This is one of the highest-leverage improvements because it reduces repeated exploration across the team.

5. Safer tool integration through MCP. MCP is powerful because it can connect an agent to additional tools and data sources. It is also a risk surface. The new per-tool controls are useful because they allow a team to decide which capabilities are acceptable in a given IDE workflow. A senior engineer should treat MCP configuration like any other integration: least privilege, explicit ownership, reviewable changes, and a clear rollback path.

How I would evaluate productivity gains

The wrong metric is whether the model feels impressive in a demo. The right metric is whether it reduces elapsed engineering time without increasing review burden or defect risk. For a team already using JetBrains IDEs, I would measure four things during a two-week trial. First, cycle time for small maintenance tasks delegated to the agent. Second, human interruptions caused by approval prompts. Third, review defects found in agent-generated diffs. Fourth, the percentage of agent sessions that complete with a usable branch or patch.

If the plugin saves twenty minutes on a refactor but adds thirty minutes of review anxiety, it is not a productivity win. If shared instructions reduce repeated context discovery and assisted approvals remove noisy prompts while preserving high-risk stops, the equation changes. The best gains are likely to appear in routine but context-heavy work: tests, docs, small migrations, cleanup, dependency updates, and PR follow-up. These are tasks where senior judgment is required but does not need to be spent typing every line.

Limitations and cautions

The first limitation is availability and plan dependency. Copilot features vary by account, organization policy, product surface, and rollout stage. Public preview features can change. Teams should validate the exact plugin version, account entitlement, and administrative settings before planning a rollout.

The second limitation is that approvals are not a substitute for review. Automatic approval for low-risk tools can improve flow, but risk classification is not the same as correctness. A read-only inspection can still lead to a poor conclusion. A generated test can still encode the wrong behaviour. A migration can still preserve compilation while changing semantics. Human review, CI, and staged release remain mandatory.

The third limitation is context quality. Agents follow the map they are given. If the repository lacks clear build instructions, test commands, architectural rules, and ownership boundaries, the agent will spend more time exploring and make more questionable assumptions. Investing in AGENTS.md, repository instructions, and path-specific guidance is not bureaucracy; it is performance tuning for agentic development.

The fourth limitation is tool sprawl. MCP servers, organization skills, custom instructions, local settings, and IDE controls can become hard to reason about if nobody owns them. The more capable the agent becomes, the more important it is to document who approves tools, how permissions are changed, and how incidents are investigated.

The senior developer takeaway

GitHub Copilot for JetBrains 1.18.0 is worth tracking because it shows where AI developer tooling is heading: not only toward better models, but toward better control surfaces. The competitive advantage for engineering teams will not come from letting agents do everything. It will come from designing a workflow where agents can handle bounded implementation work, humans shape plans and approve risky actions, and CI/CD remains the final automated gate.

If your team already works in JetBrains IDEs, this release is a good moment to run a controlled experiment. Install the plugin, write serious repository instructions, choose two low-risk task classes, observe the approval flow, and measure whether the agent reduces cycle time without weakening review. That is the practical path to productivity: not replacing senior engineers, but giving them a better delegation layer while keeping them firmly in control.

Sources