Why this JetBrains update matters for real engineering work
GitHub Copilot for JetBrains 1.18.0 is not just another assistant update; it is a useful signal about where AI developer tools are becoming practical for senior engineers. The release adds AI-assisted tool approvals for Copilot agent sessions, message re-editing with file rollback, organization and enterprise skills, plan mode for the Codex agent, and more persistent control over MCP tools. None of these features is flashy in isolation. Together, they address the real bottleneck in agentic development: how to let an agent do more work without giving up human control.
For teams that live in IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider, PhpStorm, or another JetBrains IDE, this matters because the IDE is already the place where architecture, navigation, tests, debugging, refactoring, and review happen. A coding agent that operates inside that environment can be more useful than a detached chatbot, but also more dangerous if approval, rollback, and tool boundaries are weak. The 1.18.0 update is interesting because it pushes in the right direction: less interruption on low-risk operations, more explicit review before implementation, and better control over the external tools exposed to the agent.
The main lesson is not “turn on every autonomous feature.” A senior developer should read this release as an invitation to design a better human-in-the-loop workflow. Let the agent remove repetitive friction, but keep humans responsible for intent, risk, code review, tests, and merge decisions.
What the tool is
GitHub Copilot for JetBrains is the Copilot plugin for JetBrains IDEs. JetBrains documentation describes GitHub Copilot as a third-party coding agent available in AI Assistant. It can write, debug, and explain code, perform Git operations such as committing and branching, and manage pull requests and issues on GitHub. The same documentation describes several operating modes: Agent mode, where Copilot can read and modify files and run commands; Plan mode, where it analyzes the request and produces a structured plan before changes are made; and Autopilot, where it works through a multi-step task without pausing between steps.
The September 22 GitHub changelog focuses on version 1.18.0 of the JetBrains plugin. The headline feature is AI-assisted tool approvals, called assisted approvals, currently in public preview for Copilot agent sessions. Low-risk tool calls can receive automatic approval, while higher-risk actions still prompt the developer for a decision. GitHub also added the ability to re-edit a previous user message in an agent session; before the replacement message is sent, Copilot rewinds both the conversation and file changes. That is a meaningful safety valve when an instruction was ambiguous or the agent started down the wrong path.
The release also brings shared organization and enterprise skills into both local and Copilot agent sessions, adds plan mode to the Codex agent, and improves MCP control. A new setting can turn the built-in GitHub MCP Server on or off without changing manually configured MCP servers, and Copilot agent sessions gain persistent per-tool controls for MCP servers. In simple terms: the agent can become more capable, but the developer and the organization get more levers to shape what it is allowed to do.
How to install or access it
The access path is straightforward. Install the GitHub Copilot plugin from the JetBrains Marketplace, sign in with a GitHub account that has access to Copilot, and select GitHub Copilot in the AI Assistant or chat surface of the IDE. The Marketplace page is the best download entry point, while the JetBrains documentation explains activation, context collection, operation modes, model selection, approval behavior, rollback, MCP usage, instruction files, and slash commands.
After installation, verify the plugin version. The changelog is specifically about GitHub Copilot for JetBrains 1.18.0, so teams should confirm that their IDE sees that release or a later one. Enterprises should also check account policy, enabled models, usage-based billing settings, and organization-managed instructions before asking developers to rely on the new agent workflows. The list of visible models and reasoning levels depends on what the GitHub Copilot account enables.
My recommended rollout is conservative. First, enable the plugin for a small group of senior developers on non-critical repositories. Second, create or update repository instructions so the agent knows project structure, test commands, coding conventions, and forbidden areas. Third, test Agent and Plan modes separately. Fourth, expose only the MCP tools the project actually needs. Finally, measure whether the new approval behavior reduces interruption without increasing risky changes.
Use case 1: planning before touching files
The most valuable habit is to use plan-first work for ambiguous changes. Instead of asking an agent to “fix the payment retry logic,” ask it to inspect the relevant package and produce a plan: files involved, current behavior, proposed minimal change, tests to add, commands to run, and risks. With the Codex agent now supporting plan mode in this JetBrains release, developers can review, refine, or approve an approach before implementation begins.
This matters in senior engineering work because the hard part is rarely typing code. The hard part is choosing the smallest safe change that fits the architecture. Plan mode gives the human reviewer a checkpoint before the agent edits anything. If the plan touches the wrong subsystem, ignores a migration path, or assumes a business rule that is not true, you can correct the direction early. That is cheaper than reviewing a large diff after the agent has already made a wrong assumption.
A practical workflow is: ask for a read-only investigation, request a plan, edit the plan yourself, then allow implementation only after the acceptance criteria and validation commands are explicit. The productivity gain comes from faster repository comprehension while keeping design authority with the developer.
Use case 2: fewer interruptions on routine tool calls
Approval prompts are necessary, but too many prompts train developers to click through them. Assisted approvals try to reduce this fatigue. GitHub says low-risk tool calls can be automatically approved while higher-risk actions continue to ask for a decision. Used carefully, this can make agent sessions less choppy without removing the human from meaningful choices.
The key phrase is “used carefully.” I would not enable any preview approval feature on a production-critical repository first. Start with a sandbox project, documentation task, or test-only cleanup. Watch what the agent considers low risk. Compare the experience with the traditional approval model. If the feature saves time while still prompting for commands, paths, and external access that deserve scrutiny, it can become part of the team’s default workflow.
The right mental model is risk-based autonomy. Reading a file, listing a directory, or running a harmless inspection command is not the same as editing a migration, deleting files, changing credentials, or calling an external service. Assisted approvals are useful only if they preserve that distinction in practice.
Use case 3: correcting a bad prompt without carrying the mistake forward
Message re-editing with rewind is more important than it sounds. In agent work, an early prompt often shapes the entire session. If that prompt is vague or wrong, later corrections can become messy because the agent has already modified files and built context around a false premise. The new ability to re-edit a previous user message and rewind both conversation and file changes lets a developer recover earlier.
This supports a more experimental but safer workflow. You can try a narrower instruction, inspect the direction, and if it is wrong, roll back to the point where the instruction should have been different. That is better than layering clarifications on top of a polluted session. It also encourages developers to treat prompts like code: revise them, simplify them, and keep the history clean when the direction changes.
For teams, the discipline should be clear: commit or stash important work before long agent sessions, keep tasks small enough that rewind is understandable, and do not use rollback as a substitute for reading diffs. The feature improves recovery; it does not replace review.
Use case 4: making organization instructions operational
Shared organization and enterprise skills can reduce one of the biggest sources of agent variability: every developer repeating incomplete project context in a different way. If platform or architecture teams can publish reusable skills and managed instructions, agents are more likely to follow the same conventions across local and agent sessions.
This is especially useful for large organizations. A backend team can encode how services are structured, how tests are named, which logging library is approved, how errors should be wrapped, and which directories are generated. A security team can describe prohibited patterns and review expectations. A release team can define how changelog entries and migration notes should be prepared. The agent still needs human oversight, but it starts from a better baseline.
The practical productivity gain is not only faster code generation. It is fewer review comments caused by missing local knowledge. Senior engineers spend less time repeating the same architectural guidance and more time on the exceptional decisions that actually require judgment.
Use case 5: controlling MCP tools instead of exposing everything
MCP tools are powerful because they let agents reach external systems. They are also a governance boundary. A coding agent with access to issue trackers, source control, deployment systems, observability tools, or internal documentation can be dramatically more useful, but every additional tool expands what a mistaken instruction can affect.
That is why persistent per-tool controls matter. Developers can narrow the agent’s toolset for a session, and teams can decide which tools should be available by default. Turning the built-in GitHub MCP Server on or off separately from manually configured servers is a small but useful detail: it helps teams distinguish GitHub-native access from other integrations.
My recommendation is to start with a minimal tool surface. For a bug-fix task, the agent may need repository access, tests, and perhaps the relevant issue. It probably does not need deployment tools or broad network access. For a release-preparation task, it may need changelog and pull-request context but still should not have unlimited rights. Treat tool exposure like production permissions: grant the minimum useful capability, then expand only when there is evidence.
Limitations and risks
There are clear limitations. Assisted approvals are in public preview, which means teams should expect behavior to evolve. The changelog says lower-risk actions can be approved automatically, but developers still need to verify how that classification behaves in their environment. A “low-risk” file read in one repository may be sensitive in another. A command that is harmless in a toy project can be expensive or destructive in a monorepo with custom scripts.
Agentic IDE workflows also depend on repository quality. Strong tests, clear package boundaries, documented setup commands, and good instructions make the agent more useful. Weak tests and implicit business rules make it easier for an agent to produce plausible but wrong changes. The tool amplifies the engineering system around it; it does not magically create governance where none exists.
Finally, cost and attention matter. Model calls, reasoning levels, tool calls, and repeated sessions consume budget. Review time is also a cost. A team should track whether agent-created changes reduce total cycle time after review and rework, not just whether they create code quickly.
A senior developer’s adoption checklist
- Upgrade to the current GitHub Copilot plugin for JetBrains and verify the version in the IDE.
- Read the JetBrains operation-mode documentation before enabling autonomous workflows.
- Add repository instructions that include architecture, test commands, generated files, security constraints, and forbidden paths.
- Use Plan mode for ambiguous changes and require human approval before implementation.
- Trial assisted approvals on low-risk repositories before using them on critical code.
- Keep MCP exposure minimal and persistently disable tools that are not needed for the task.
- Require normal pull-request review, CI, branch protection, and code-owner approval for agent-produced changes.
- Measure accepted PRs, rejected PRs, review time, CI failures, regressions, and developer interruption count.
The productivity gain
The gain from this release is not that Copilot can act without a developer. The gain is that the agent can do more of the repetitive navigation, planning, editing, and validation inside the IDE while the developer keeps control of the important gates. Assisted approvals reduce low-value interruptions. Plan mode creates a checkpoint before code changes. Re-edit and rewind improve recovery. Organization skills reduce repeated guidance. MCP controls keep tool access intentional.
That is the direction AI developer tools need to go: not generic hype, but better engineering ergonomics around supervised autonomy. For a senior engineer, the opportunity is to design workflows where agents handle bounded execution and humans retain authority over architecture, safety, and release decisions. Used that way, GitHub Copilot for JetBrains 1.18.0 can save real time without asking teams to surrender responsibility.
