AI coding assistants are moving beyond code completion. In an agentic workflow, an assistant can inspect project files, edit code, run commands, use external tools, and continue working through several steps to complete a development task.
That added capability creates an important question: what should an AI agent be allowed to do automatically, and when should a developer be asked for approval?
GitHub Copilot for JetBrains 1.18.0 introduces AI-assisted tool approvals, called assisted approvals, for Copilot agent sessions. Low-risk tool calls can receive automatic approval, while higher-risk actions can still require a developer decision.
This changes the approval workflow without removing developer control over actions that deserve closer inspection.
Why Tool Approvals Matter
Traditional code completion is relatively low risk.
The assistant suggests:
Code
|
v
Developer Reviews
|
v
Developer Applies
An agentic coding workflow is different:
Developer Request
|
v
AI Agent
|
+---- Read files
|
+---- Search code
|
+---- Edit files
|
+---- Run commands
|
+---- Run tests
|
v
Completed Task
The agent may therefore interact with the development environment instead of simply returning text.
Consider a request such as:
Add validation to the registration API,
update the unit tests, and run the affected tests.
Completing that task could require several tool calls.
Some operations are routine. Others can modify the filesystem or execute commands with broader consequences.
Approval controls provide a boundary between those operations.
What Changed in JetBrains 1.18?
GitHub Copilot for JetBrains 1.18.0 introduced assisted approvals in public preview.
Under this approach, lower-risk tool calls can be automatically approved, while higher-risk operations continue to require user confirmation.
The goal is to reduce unnecessary interruptions during normal agent work without treating every tool call as equally safe.
Conceptually:
Agent requests tool
|
v
Risk / approval handling
|
+----+----+
| |
Low risk Higher risk
| |
v v
Auto Ask user
approve for approval
The exact behavior depends on the configured Copilot permissions and the tool being requested.
From Manual Approval to Assisted Approval
A fully manual workflow can become repetitive.
Imagine an agent needs to inspect ten project files:
Read file 1 -> Approve
Read file 2 -> Approve
Read file 3 -> Approve
...
Read file 10 -> Approve
That creates unnecessary friction if the operations are low risk.
Assisted approvals aim to reduce those interruptions.
Instead, the workflow can become:
Read low-risk file
|
v
Automatically approved
|
v
Continue analysis
|
v
Request higher-risk operation
|
v
Developer approval
This lets the agent continue routine work while preserving a checkpoint for more sensitive actions.
What Counts as a Tool Call?
A tool call is an operation the agent performs through an available development capability.
Depending on the workflow, examples can include:
Reading project files
Searching the repository
Editing files
Running terminal commands
Running tests
Interacting with configured MCP tools
Accessing development resources
The important distinction is between generating an instruction and executing an operation.
For example, the assistant can suggest:
dotnet test
That is different from actually executing the command.
Once the agent can execute operations, permissions become an important part of the workflow.
Why Low-Risk and High-Risk Actions Should Be Treated Differently
Not every action has the same potential impact.
For example:
Operation | Typical Consideration |
|---|
Read a source file | Usually lower impact |
Search repository | Usually lower impact |
Inspect test output | Usually lower impact |
Modify source code | Requires review |
Delete files | Higher impact |
Run arbitrary shell commands | Potentially higher impact |
Change project configuration | Potentially higher impact |
Access external services | Depends on permissions and tool |
Modify infrastructure | Potentially high impact |
This is why a single global approval rule can be difficult to manage.
Developers need enough automation to remain productive while retaining control over meaningful changes.
A Practical Example
Suppose you ask Copilot:
Find the authentication service,
add validation for expired tokens,
and update the related tests.
The agent may need to:
Search the project.
Read authentication files.
Inspect existing tests.
Modify the service.
Modify tests.
Run the test suite.
Inspect failures.
Make corrections.
A simplified workflow looks like this:
Search repository
|
v
Read authentication code
|
v
Read tests
|
v
Modify service
|
v
Modify tests
|
v
Run tests
|
v
Review result
The approval system determines which of those operations can proceed automatically and which require user interaction.
Approval Does Not Replace Code Review
One important distinction is that tool approval and code review solve different problems.
Tool approval asks:
Should the agent perform this operation?
Code review asks:
Is the resulting change correct?
A developer might approve an edit because it is appropriate for the task and still discover that the implementation is incorrect.
For example:
if (token.Expired)
{
RefreshToken();
}
The code may compile successfully but still introduce a logic problem if the refresh operation is not thread-safe or if retry behavior is incorrect.
Approval does not establish correctness.
Reviewing the Final Diff
After an agent completes a task, review the resulting changes.
For a Git repository, a basic workflow might include:
git status
followed by:
git diff
The goal is to verify:
Expected files changed
No unrelated files were modified
No sensitive configuration was added
Tests were updated appropriately
The implementation follows project conventions
The generated changes match the original request
This remains necessary even when the agent's summary looks correct.
Tool Approvals and Terminal Commands
Terminal access deserves particular attention.
A command such as:
dotnet test
is very different from an arbitrary command that modifies the filesystem.
For example:
rm -rf build/
can have a destructive effect depending on the working directory.
Likewise, a package-management command can change project dependencies.
A useful development practice is to understand the command before approving execution.
Do not treat every approval request as equivalent.
Tool Approvals and File Changes
File modifications also deserve review.
Suppose an agent says:
I will update UserService.cs and UserServiceTests.cs.
The developer should verify that those are actually the files changed.
An unexpected modification to:
appsettings.json
or:
package-lock.json
could have implications unrelated to the requested feature.
This is why version control remains an important safety mechanism.
MCP Tools Add Another Layer
Model Context Protocol, or MCP, allows AI systems to interact with external tools and services.
GitHub's JetBrains integration provides controls for MCP tools, including persistent per-tool controls in agent sessions. Version 1.18 also added a setting for enabling or disabling the built-in GitHub MCP Server independently of manually configured MCP servers.
This matters because an MCP tool can potentially do more than inspect local source code.
For example, the GitHub MCP Server can expose actions involving repositories, issues, and pull requests through Copilot Chat.
That makes tool-level control particularly useful.
Why MCP Permissions Need Attention
Consider an agent working on a bug.
It might need to inspect repository information:
Repository
|
+---- Issues
|
+---- Pull Requests
|
+---- Files
But the developer may not want the agent to automatically create or modify GitHub resources.
The difference is significant:
Read repository information
versus:
Create a pull request
Both are tool operations, but their impact is different.
A sensible workflow keeps permissions aligned with the actual task.
Persistent Tool Controls
One useful aspect of the newer JetBrains workflow is persistent control over individual MCP tools.
Instead of repeatedly deciding about the same tool during every session, developers can configure how that tool should be handled.
This can reduce repetitive approval prompts for trusted operations.
At the same time, developers should be careful when creating persistent permissions.
A permission that is convenient today can become risky when the task or repository changes.
Enterprise Governance
Tool approval becomes even more important in enterprise environments.
Organizations may have requirements around:
Source-code access
External services
MCP servers
Developer tooling
Telemetry
Permission modes
Plugin management
GitHub has also added enterprise-managed settings for Copilot in JetBrains, including controls for MCP server access and permission behavior. Administrators can centrally manage allowed and denied MCP servers and can prevent bypass permission modes for organizational users.
This creates a layered model:
Enterprise Policy
|
v
IDE Configuration
|
v
Copilot Permissions
|
v
Individual Tool
|
v
Agent Action
Developers therefore may not have complete control over every permission setting in an enterprise-managed environment.
Assisted Approvals vs Full Auto-Approval
These approaches should not be confused.
Assisted approval:
Low-risk action
|
v
Automatic approval
Higher-risk action
|
v
Developer approval
Full auto-approval is broader.
Earlier JetBrains Copilot updates introduced global auto-approval and granular controls for terminal commands and file edits. GitHub explicitly notes that global auto-approval can cover potentially destructive actions, so it should only be enabled when the associated risks are understood.
For most development workflows, the important question is not simply:
Can I remove approval prompts?
It is:
Which operations am I comfortable allowing automatically?
A Safer Configuration Strategy
For a normal development project, a practical approach is to separate operations into categories.
Category 1: Routine Read Operations
Examples:
Search source files
Read project files
Inspect test output
Analyze existing code
These operations are often suitable for more automation.
Category 2: Controlled Write Operations
Examples:
Modify source files
Modify tests
Update configuration
These should still be reviewed through the final diff.
Category 3: Sensitive Operations
Examples:
Delete files
Execute unfamiliar commands
Change infrastructure configuration
Access external systems
Modify production-related resources
These deserve stronger approval requirements.
How to Review an Approval Request
Before approving a tool request, ask four simple questions.
What Is the Tool Doing?
Understand the actual operation rather than relying only on a short description.
Why Is It Needed?
Does it directly contribute to the task?
What Could It Change?
Consider files, dependencies, external resources, or configuration.
Can the Result Be Easily Reverted?
A source-code edit committed in Git is generally easier to recover than an irreversible external operation.
This mental checklist takes only a few seconds and can prevent unnecessary risk.
Common Mistakes
Approving Everything Automatically
Removing all approval friction can also remove useful safety boundaries.
Confusing Approval With Trust
Approving one operation does not mean every future operation is safe.
Ignoring MCP Permissions
An MCP server may expose capabilities beyond ordinary file editing.
Not Reviewing the Diff
Even approved changes can be incorrect.
Running Agents in Sensitive Environments
Development environments should be separated from production credentials and resources wherever possible.
Giving an Agent an Overly Broad Task
A bounded task is easier to monitor and validate.
Troubleshooting Unexpected Tool Behavior
If Copilot repeatedly asks for approval for an operation you expected to be automatic, check the current permission and tool configuration.
Also consider whether the requested operation has moved into a higher-risk category.
If an agent refuses to perform an operation, verify:
The required tool is enabled.
The relevant MCP server is available.
Organization policies are not blocking the operation.
The current permission mode allows the action.
The agent has the required context.
The task actually requires the requested tool.
For enterprise-managed environments, administrator policies can take precedence over developer settings. GitHub has also introduced enterprise-managed sandbox controls covering areas such as filesystem and network access.
Tool Approvals and Developer Productivity
Approval systems can appear to add friction, but excessive approval prompts can also interrupt development.
Imagine an agent making a sequence of harmless repository searches:
Search 1 -> Approval
Search 2 -> Approval
Search 3 -> Approval
Search 4 -> Approval
The developer spends more time approving operations than reviewing the resulting work.
Assisted approvals attempt to solve that problem by allowing lower-risk operations to proceed automatically while preserving additional checks for higher-risk actions.
The goal is therefore not maximum automation.
It is appropriate automation.
Best Practices for Developers
Keep the Task Specific
Instead of:
Fix everything related to authentication.
use:
Update expired-token handling in the authentication service
and add tests for the affected scenarios.
A narrower task produces a more predictable tool sequence.
Review High-Impact Operations
Pay particular attention to:
File deletion
Dependency changes
Shell commands
Configuration changes
External service calls
Database operations
Review the Final Diff
Use normal source-control review even when all tool operations were approved.
Keep Production Credentials Away From Development Agents
Do not expose secrets simply because an agent can technically access the environment.
Use Enterprise Controls Where Appropriate
Organizations should centrally manage MCP servers and permission policies when consistent governance is required.
Test the Result
Run the relevant tests after the agent completes its work.
For example:
dotnet test
or:
mvn test
depending on the project.
Advantages
Fewer Interruptions
Low-risk tool calls can proceed without requiring constant manual approval.
Better Agent Workflows
Agents can complete multi-step tasks more naturally.
More Granular Control
Developers can distinguish between routine and higher-risk operations.
Better MCP Governance
Persistent tool controls make it easier to manage individual MCP capabilities.
Enterprise Policy Support
Organizations can apply centralized controls to permission behavior and MCP access.
Disadvantages and Limitations
Automation Can Increase Risk
An automatically approved action can still produce an unwanted result.
Configuration Can Become Complex
Multiple layers of permissions can make troubleshooting harder.
Enterprise Policies May Override Local Settings
Developers may not be able to change certain controls.
Approval Does Not Guarantee Correctness
A permitted action can still introduce a software defect.
External Tools Need Additional Review
MCP integrations can expand what an agent can access or modify.
A Practical Approval Workflow
For day-to-day development, a simple workflow is:
Define the task clearly.
Let the agent inspect the project.
Allow routine low-risk operations where appropriate.
Review requests involving writes or external tools.
Check the resulting diff.
Run targeted tests.
Run broader tests when required.
Review the final change before committing.
This keeps the developer involved without requiring manual approval for every minor operation.
What This Means for AI-Assisted Development
Tool approvals are becoming an important part of agentic software development.
The core challenge is no longer simply generating correct code. An AI agent may need to interact with the development environment to complete a task.
That creates a second engineering problem:
How much autonomy should the agent have?
JetBrains 1.18 moves toward a more adaptive answer by allowing low-risk operations to proceed with less interruption while maintaining approval checkpoints for higher-risk actions.
The approach is especially relevant as agents gain access to MCP servers, terminal commands, project files, and other development tools.
Summary
GitHub Copilot's new tool approval capabilities in JetBrains IDEs are designed to make agentic development less repetitive without removing important safety controls.
Assisted approvals can automatically handle lower-risk operations while higher-risk actions can still require developer confirmation. Persistent controls also give developers more control over individual MCP tools, while enterprise policies can provide additional governance.
For developers, the important practice is to treat approval as one layer of control, not as a replacement for code review or testing.
A strong workflow combines bounded tasks, appropriate permissions, careful review of tool actions, version control, and automated tests. As AI agents become capable of doing more inside the IDE, controlling what they can do becomes just as important as evaluating the code they produce.
James LeoPosted Sep 23, 2026, 12:19 PM
Totally agree that striking the right balance here is key. Having to manually click approve every single time an agent wants to read a file gets old fast, but giving it full autonomous reign over terminal commands feels like asking for trouble. Glad to see JetBrains and Copilot moving toward a more nuanced approach with assisted approvals. Still definitely keeping my eyes glued to git diff afterward though, haha.