What happened
GitHub shipped Copilot for JetBrains 1.18.0, an update to how Copilot works inside JetBrains IDEs, the family of code editors that includes IntelliJ, PyCharm, and WebStorm. The headline change is what GitHub calls “assisted approvals,” now in public preview. When Copilot’s agent wants to do something beyond suggesting text, such as running a command, editing a file, or calling an external tool, it normally stops and asks you to approve it first. That approval prompt is the checkpoint where you catch a bad action before it happens. With assisted approvals on, GitHub says “low-risk tool calls receive automatic approval, while higher-risk actions continue to prompt you for a decision.”
The same release adds a few other changes. You can now re-edit an earlier message in a Copilot agent session, and Copilot rewinds both the conversation and any file changes made since that point before it acts on your revised request. Organizations can now share skills and custom instructions across both local and cloud agent sessions. And Codex, OpenAI’s coding agent, which Copilot can also run as one of its agent options, now supports a plan mode: it shows you a plan before making changes, which you can review or adjust before it starts.
What the changelog doesn’t say is what “low risk” actually means, whether assisted approvals is on by default, or how to see afterward which actions it approved without asking you.
Why it matters
Approval prompts exist because an agent acting on your codebase can do something you didn’t intend, and the prompt is your last chance to stop it before it happens. Automating that decision for a category of actions is a reasonable idea in principle. Constant approval requests for genuinely harmless actions train people to click through them without reading, which defeats the point of having them at all.
But automating it without publishing the criteria shifts real risk onto you. If you don’t know what GitHub classifies as low risk, you can’t predict what will run without asking first. And if there’s no visible record of what got auto-approved in a session, you can’t check afterward either. That combination, an opaque rule plus no audit trail, is exactly the setup where a builder discovers a problem only after an agent has already made the change.
This isn’t the first time a coding agent’s permission model has come under scrutiny. Last week, BuilderWithin covered how Meta’s Muse compares to Claude Code and Codex on what it asks permission for, a reminder that permission design varies a lot between tools and isn’t something you can assume works the same way twice.
Who should care
Anyone running Copilot’s agent inside a JetBrains editor, especially if you’ve come to rely on the approval prompt as your signal to stop and read what the agent is about to do.
What builders should do next
Test it before you trust it. After you’re on 1.18.0, run two separate agent sessions. In one, ask for something you’d call routine, like listing files in a folder or reading a config file. In the other, ask for something you’d call risky, like deleting a file or running a script that writes to a database. Watch whether assisted approvals stays out of the way for the first and still stops you for the second. Then check your JetBrains settings for wherever this preview toggle lives, and look for any log or history that shows what got auto-approved during the session. If you can’t find one, that’s the practical gap: no visible history means you’re trusting the classification without a way to verify it after the fact. Until GitHub publishes clearer criteria, that’s a reasonable point to turn assisted approvals off and keep approving actions yourself.
Where this fits
GitHub is trying to solve real approval fatigue, the same problem every agent maker with a permission system eventually runs into. The fix just arrived without the part that would let you verify it’s drawing the line where you’d draw it yourself. Worth watching whether GitHub publishes the missing criteria before this preview becomes the default.
End of article