Copilot for JetBrains can approve some tool calls for you

GitHub Copilot for JetBrains 1.18.0 can approve some agent tool calls without interrupting the developer. In the September 22 release, GitHub calls this public-preview feature assisted approvals: low-risk calls receive automatic approval, while higher-risk actions still ask the user. For an engineering team, fewer prompts are useful only if the remaining prompts appear where the team expects them.

The release also adds persistent controls for individual MCP tools in Copilot agent sessions. Those controls answer a different question: which tools are available to the agent at all? An allowed tool can still require a decision at execution time. Keeping access and approval separate makes a pilot easier to interpret.

What the new approval path does

In a normal agent session, the coding assistant may ask to run a tool as it inspects and changes a project. Assisted approvals let Copilot make the low-risk approval decision for some calls. GitHub says higher-risk actions continue to prompt the developer. The announcement does not publish a complete risk-classification rule or promise that any particular command will always produce the same prompt, so a team should observe the behavior on its own supported plugin version rather than infer a fixed list from the description.

This is distinct from Bypass Approvals or Autopilot, which the earlier JetBrains managed-settings pilot discusses as modes an enterprise can disable. Assisted approvals are described as a selective prompt path, not an allow-all mode. The managed sandbox analysis covers another separate layer: what the agent can access when a tool actually runs. Neither an approval nor a sandbox setting judges whether the resulting code is correct.

Set tool availability before measuring prompts

JetBrains 1.18.0 adds a switch for the built-in GitHub MCP Server without changing manually configured MCP servers. GitHub says the built-in server remains enabled by default. The update also adds persistent per-tool controls for MCP servers in agent sessions. An owner can use these controls to narrow the available tools before evaluating how approvals behave, then record which server and tool settings were active during each run.

A practical test uses a disposable repository with no production credentials. Run a small agent task that reads a file and proposes a change, then a separate task that would invoke a tool or action your team regards as sensitive. Record the plugin version, available MCP tools, assisted-approval setting, exact proposed calls, prompts shown, actual file changes, and whether the developer declined or approved. These are proposed pilot observations, not reported results of a BaristaLabs product test. If a sensitive call proceeds without the review your policy requires, stop that configuration rather than extrapolate from GitHub's “higher-risk” wording.

Scroll sideways to see all 2 columns.

Pilot observation	What to record
Available tools	Built-in server state and enabled individual MCP tools
Approval behavior	Proposed tool call, automatic decision or human prompt, and time
Outcome	Files changed, external effects, and whether the resulting change passed review

The release also lets a developer re-edit an earlier message after Copilot rewinds the conversation and file changes. That is useful for correcting direction, but it is not evidence that external side effects have been undone. Keep the pilot's review record independent of the conversational rewind.

Teams already managing JetBrains policy support do not need another broad permissions inventory for this release. The new decision is narrower: whether the selective approval path saves interruptions without silently approving a call your team would have reviewed. If you need help designing that test, talk with BaristaLabs about an agent pilot.