Why this release matters for senior engineers
GitHub Copilot for JetBrains 1.18.0 is not just another IDE assistant update. The September release adds a set of controls that make agentic development more usable in real engineering environments: AI-assisted tool approvals, the ability to re-edit earlier agent prompts, shared organization skills and instructions, Codex agent plan mode, and persistent controls for MCP tools. For a senior engineer, the useful part is not that the agent can write more code. The useful part is that the tool is getting closer to the workflow we actually need: delegate routine implementation, keep a clear review trail, and reserve human judgment for design, risk, and release decisions.
This is the productivity pattern that matters in 2026. The bottleneck in AI-assisted development is often no longer “can the model produce a patch?” It is “can I let it work long enough without either babysitting every harmless command or granting it too much power?” Copilot for JetBrains 1.18.0 addresses that middle ground. Low-risk tool calls can be approved automatically in public preview, while higher-risk actions still prompt the developer. The team can share instructions and skills, the developer can inspect or adjust a plan before implementation, and MCP tools can be controlled with more persistence instead of being accepted blindly.
What the tool is
GitHub Copilot for JetBrains is the GitHub Copilot integration for IntelliJ IDEA, PyCharm, WebStorm, GoLand, PhpStorm, RubyMine, Rider and the broader JetBrains IDE family. In current versions it is more than autocomplete. It exposes chat, agent sessions, repository-aware coding help, GitHub context, and integrations with coding agents that can plan and make changes across a project. Version 1.18.0 focuses on the control layer around those sessions.
The release is especially interesting for teams that already live in JetBrains IDEs and want to move from local prompt-and-paste usage to structured agent workflows. A developer can ask an agent to add tests, update an endpoint, migrate a small module, or explore a bug. The new features help define how much autonomy the agent receives and how much evidence the human sees before accepting the work.
- Assisted approvals: low-risk tool calls can be approved automatically, reducing interruptions, while higher-risk operations still require explicit human approval.
- Re-edit earlier messages: if the initial request was wrong, the session can rewind the conversation and file changes so the developer can correct the instruction at the right point.
- Shared skills and instructions: organization and enterprise guidance can be used in local and Copilot agent sessions, giving agents a better chance of following team conventions.
- Codex plan mode: the Codex agent can present a plan for review, refinement, or approval before it starts changing code.
- MCP controls: the built-in GitHub MCP Server can be switched on or off separately, and individual MCP tools can be managed with persistent per-tool controls.
How to install or access it
If you already use a supported JetBrains IDE, install or update the GitHub Copilot plugin from the JetBrains Marketplace inside the IDE. Open the IDE settings, go to Plugins, search for GitHub Copilot, install or update it, then sign in with a GitHub account that has access to Copilot. Existing users should check that the plugin has moved to the 1.18.x line or later.
The release notes are the best starting point for what changed in this specific version. For agent behavior beyond the IDE, GitHub’s Copilot documentation explains how Copilot cloud agent can research a repository, create an implementation plan, make changes on a branch, run tests or linters in an ephemeral environment, and let the developer review and iterate before a pull request is created. The same documentation also explains how to manage agent sessions, inspect logs, steer a running task, stop it, archive it, and trace commits back to session logs.
In practice, I would roll this out in three steps. First, update the plugin for a small group of experienced developers. Second, define which repositories and task types are safe for agent sessions: tests, documentation, small refactors, low-risk bug fixes, or maintenance tickets. Third, write shared instructions that describe the team’s architecture rules, test commands, formatting expectations, security boundaries, and pull request style. Without that third step, every developer ends up rediscovering the same prompt boilerplate.
Concrete workflow: let the agent prepare, not decide
The strongest use case is a small-to-medium maintenance task where the destination is known but the mechanical work is annoying. Example: a service has inconsistent validation errors across several endpoints. A senior engineer can ask Copilot to inspect the current patterns, propose a plan, update the implementation, add tests, and report what changed. With plan mode, the developer can stop before implementation and check whether the agent has understood the boundaries: reuse the existing validation utility, avoid public API changes, preserve backward compatibility, and add regression tests around the failing cases.
This is where human-in-the-loop control becomes practical rather than ceremonial. The human is not approving every file read. The human is approving the strategy, the risk envelope, and the final diff. Assisted approvals remove low-value interruptions, while the high-value approvals remain exactly where they belong: commands that can mutate significant state, access sensitive resources, or change the direction of the task.
Use case 1: test coverage that follows local conventions
Senior engineers often know where tests are missing, but writing the tenth variant of the same test is not the best use of their attention. Copilot agent sessions can be useful for adding focused test coverage around known behavior. In a JetBrains project, ask the agent to identify the existing test style, add coverage for a specific branch, run the relevant test command, and summarize failures without broad refactoring. Shared organization instructions help here because they can encode the team’s preferred test framework, fixture style, naming convention, and “do not introduce new dependencies without approval” rule.
The productivity gain is not magic code generation. It is reducing the cost of doing the responsible thing. If writing tests becomes a five-minute supervision task instead of a thirty-minute context-switch, teams are more likely to add the tests before merging the fix.
Use case 2: safe dependency and API migrations
Another practical use case is a contained migration: rename a deprecated API call, replace one internal helper, or update usage of a library where the migration pattern is repetitive. The developer can ask for a plan first, verify the search strategy, approve implementation, then inspect the diff and test output. Re-editing earlier messages is valuable because migration prompts are often slightly wrong on the first attempt. If the agent starts from a bad assumption, the developer can correct the earlier instruction and rewind instead of stacking more confusing follow-up prompts on top.
This is a small feature with a large workflow effect. Long agent sessions can otherwise become messy: one instruction, three corrections, two partial diffs, and a final state that is hard to reason about. Re-editing an earlier request makes the session closer to a controlled branch operation. The developer can replace the faulty premise and let the tool rebuild from a cleaner history.
Use case 3: repository navigation for unfamiliar code
Senior developers spend a surprising amount of time building a mental map of code they did not write. Copilot sessions can help by exploring a subsystem and reporting the relevant files, entry points, data flow, and tests. The important instruction is to ask for evidence: file paths, functions, and commands run. GitHub’s agent-session documentation notes that session logs show the tools used to understand the repository, make changes, and validate work. That trace matters for trust. A summary without traceability is just another confident assistant answer; a summary tied to files and logs becomes something a reviewer can challenge.
For onboarding, incident follow-up, or pre-refactor analysis, this can save time. The developer still owns the architectural conclusion, but the agent can gather the map.
Use case 4: MCP tools with explicit boundaries
MCP has become a powerful way to connect agents to external systems: GitHub, issue trackers, documentation stores, internal search, databases, and more. The risk is obvious. A tool that can read a ticket is very different from a tool that can modify production data. Copilot for JetBrains 1.18.0 adds more persistent control over MCP tools and a separate setting for the built-in GitHub MCP Server. That is useful because permission fatigue is real. If every tool prompt looks the same, developers eventually click through them.
A better setup is to classify MCP tools by risk. Read-only documentation search may be broadly available. Issue creation may require confirmation. Anything that writes to source control, changes secrets, opens network access, or touches production should remain tightly controlled. Assisted approvals should reduce friction only after the team has decided what “low risk” means in its environment.
Limitations and risks
This release does not remove the need for engineering judgment. Assisted approvals are still a preview feature, so teams should treat them as an optimization layer, not a compliance guarantee. Agents can still misunderstand the codebase, overfit to nearby examples, add unnecessary abstractions, or pass a narrow test while missing the broader product requirement. Shared instructions help, but they are not a substitute for ownership.
There is also a cost-management dimension. Agent sessions consume credits and can run longer than expected. GitHub’s documentation mentions monitoring token usage and session length from the agents panel. That should be part of team hygiene. If a task is vague, the agent may spend a lot of budget exploring. Senior engineers should write prompts with a clear boundary: target files if known, acceptance tests, commands to run, and explicit non-goals.
Finally, remember that a good agent workflow is auditable. Keep changes in branches, require pull requests, use code review, run CI, and make sure generated changes are owned by a human. The agent can prepare the work; the team must still decide whether the work belongs in the product.
Productivity gain: where the time is actually saved
The biggest gain from this release is not a single spectacular demo. It is the compounding effect of reducing micro-friction. Fewer low-risk approval popups means the agent can finish routine steps. Plan review means the senior engineer catches bad direction before code changes spread. Shared instructions mean fewer repeated explanations. MCP controls mean useful context can be available without turning every integration into an all-or-nothing security decision.
For a senior engineer, this translates into a better allocation of attention. Let the agent perform the repetitive implementation passes, test additions, search operations, and first draft of the diff. Spend human attention on system design, data safety, migration strategy, review, and release criteria. That is the version of AI-assisted development that scales: not blind autonomy, not endless babysitting, but delegated execution with visible controls.
Recommended adoption checklist
- Update the JetBrains Copilot plugin and confirm the 1.18.x feature set is available for your account and IDE.
- Start with low-risk repositories or low-risk task classes: tests, documentation, small bug fixes, and narrow refactors.
- Create shared instructions for build commands, test commands, coding style, dependency policy, security rules, and pull request expectations.
- Use plan mode for any task that touches architecture, public APIs, data migrations, authentication, authorization, or performance-sensitive paths.
- Classify MCP tools by risk and keep write-capable tools behind explicit approval.
- Review session logs, diffs, and test output before merging. Never treat an agent-completed task as automatically production-ready.
My take: GitHub Copilot for JetBrains 1.18.0 is worth evaluating because it improves the control surface around agent work. The best senior engineers will not use it to abdicate decisions. They will use it to turn more implementation work into reviewable, test-backed drafts while keeping humans in charge of what matters.
