GitHub Copilot for JetBrains 1.18.0 offers developers a useful bargain: fewer decisions about individual tool calls, alongside more ways to shape what an agent can do. The unresolved part is who determines which decisions can safely disappear. GitHub says its new assisted approvals automatically approve low-risk tool calls while higher-risk actions still require a user decision. The feature is in public preview. The supplied announcement does not explain the boundary between those categories. GitHub’s release notes
That gap matters more than the number of settings. The release adds genuine opportunities for developers to constrain agents, including plan review and persistent controls for individual tools. It also introduces an approval mechanism that can act without a fresh human decision. The defensible reading is that developer control is changing form: some authority moves upstream into plans and tool settings, while the platform supplies the mechanism that decides when to ask again.
Three boundaries inside the editor
GitHub documents controls at several distinct points in the workflow. With the Codex agent’s plan mode, developers can review, refine, or approve an approach before implementation. For Copilot agent sessions, persistent per-tool controls let users manage individual tools on MCP servers. A separate setting turns the built-in GitHub MCP Server on or off without changing manually configured servers; the built-in server remains enabled by default. Assisted approvals address the decision about whether an individual tool call proceeds. GitHub’s release notes
These features govern different questions. Plan review lets a developer shape the intended approach before changes begin. Tool controls govern the tools available to the session. Assisted approvals govern when execution needs another human decision. Treating all three as interchangeable measures of “control” would obscure where authority actually sits.
A framework published by the Knight First Amendment Institute helps clarify the distinction. It treats autonomy as the extent to which an agent is designed to operate without user involvement, and distinguishes that from agency, which can be constrained by limiting the tools available. Applied here, assisted approvals concern involvement in execution, while per-tool controls concern the available scope of action. That is an analytical mapping of the features, rather than a classification supplied by GitHub. Knight Institute’s autonomy framework
The implication is that an agent can have fewer available tools and still proceed with less supervision when using them. Conversely, reviewing a plan does not by itself explain which later actions will trigger an approval request. Developers evaluating the release therefore need to assess the controls together, rather than assume that any one of them establishes the complete boundary.
The power in deciding when to ask
“Low-risk” carries much of the governance burden in GitHub’s description. It is the category that allows a tool call to proceed automatically. Yet the supplied release excerpt does not identify the classification criteria, explain how a decision is communicated, or establish whether a developer or administrator can change those criteria.
This is an evidence limit, not proof that such capabilities are absent. It does mean the announcement cannot establish how much authority users have over the approval boundary. A tool setting and a risk decision solve different problems: choosing which tools are available does not necessarily explain why a particular use of an available tool can proceed without asking.
The built-in server’s enabled-by-default status presents a more concrete allocation of authority. GitHub supplies the starting configuration and users gain an explicit switch to change it. That is both a platform choice and a developer control. The evidence does not establish how often users change the default, whether organizations impose additional restrictions, or whether the default has caused harm.
The governance question is therefore narrower than a claim that GitHub is taking autonomy away. How much of the boundary can developers deliberately set, and how much depends on the platform’s approval judgment? Persistent controls answer part of that question. The supplied explanation of assisted approvals leaves another part open.
The strongest case for greater developer autonomy
The counterargument deserves substantial weight. Reviewing an approach before implementation gives developers an earlier point of influence. Managing individual MCP tools provides a finer choice than simply accepting or disabling a whole server. The ability to disable the built-in server without changing manually configured ones is a specific, documented form of configuration independence. Those are meaningful controls, not merely reassuring language. GitHub’s release notes
Fewer approval prompts also need not mean weaker oversight. Anthropic reports that, in its research on Claude Code, experienced users tend to auto-approve more actions while also interrupting more. It argues that agent oversight requires trustworthy visibility and straightforward intervention mechanisms, beyond placing a human in an approval chain. This is vendor research about Anthropic’s own agent and API usage, not an independent assessment of Copilot or evidence that assisted approvals are safe. Anthropic’s autonomy research
Still, the finding offers a credible alternative interpretation: developers may exercise control through monitoring and intervention rather than approving every step. On that interpretation, delegating routine approval can coexist with greater influence over the work as a whole.
The limit is that the supplied Copilot evidence establishes features, not outcomes. It contains no user study showing how the controls affect developer autonomy, no evaluation of approval errors, and no measured security improvement. It supports neither a verdict of platform overreach nor a demonstrated productivity or safety gain.
What would make the bargain accountable?
JetBrains’ own guidance describes agent autonomy as bounded by permissions, runtime rules, approval flows, monitoring, and escalation paths. It recommends minimal permissions, observable behavior, and a tested rollback plan for systems with write access. This is deployment guidance from an IDE vendor, rather than validation of Copilot’s implementation. Its relevance is the distinction between allowing action and retaining the means to supervise its consequences. JetBrains’ guidance on autonomous agents
For Copilot, the concrete signal to watch is whether documentation and evaluation make the assisted-approval boundary understandable and controllable: what qualifies as low-risk, how users can inspect those decisions, and what recourse they have when the judgment is wrong. Those are questions the supplied announcement leaves unresolved.
The release gives developers more ways to set limits. Whether it also gives them sufficient authority over the limits they delegate remains the consequential test. An approval prompt is only one expression of control; the power to decide when that prompt disappears is another.
