The checkpoint - reviewing risky commands

Picture the riskiest run in this course: the shared library is open (shared-lib, the course’s illustrative internal library, imported by about a dozen services), you are on Manual permissions, and the Agent role (Copilot’s role that edits files and runs commands) is working - planning the change, reading the code. Then it stops. It wants to run the test suite - a terminal command - and at the manual default, terminal commands, file edits, and external tool calls are held for confirmation, so it surfaces the exact action and waits for your word.

This is the checkpoint. At the manual default, it is the one place the autonomy pauses for a human by default - and on shared code, it is your single best defense.

What the checkpoint actually is

Agent runs safe actions on its own - reading files and searching the codebase. But when it wants to act beyond that - a terminal command (the test suite included), a file edit, an external tool call - it does not just do it. It shows you the exact action it intends and holds until you approve. That is not Copilot being timid; that is the permission level doing its job - control, enforced rather than requested. The whole reason you chose Manual over Allow all is this dialog: the chance to see a consequential action before it executes, on code where executing the wrong one ripples through a dozen services.

Read it, don’t dismiss it

The failure mode here is not the tool. It is you, three approvals deep, treating the prompt as a doorbell to silence. When the checkpoint fires, actually read it:

1. What is it about to run? Read the literal command. A local test run and a package publish are very different, and on a shared library the difference is who it reaches.
2. Why does it want to run it now? Tie the action back to the step it is on. If it is reaching for something you did not expect - touching a registry, pushing a tag, anything that leaves your machine - that mismatch is the signal to stop and ask before you approve.
3. Is this reversible? A command you can undo locally is cheap; one that publishes a new library version the moment it lands is not. Reserve your closest reading for the ones you cannot walk back.

If it is right, approve and Copilot continues. If it is wrong, you do not approve - you say so in the conversation (“do not publish yet, run the consumer tests first”) and it re-plans around your answer. The checkpoint is not a gate you eventually wave everything through; it is a conversation about each consequential move.

Feel the doorbell effect for yourself. The session below hits a run of routine checkpoints, then a destructive command arrives on the same reflex - and playback stops with the prompt in your hands. Two caveats on the costume: the commands wear a terminal agent’s clothes in a different repo and task, and the demo’s starting policy differs from the manual default (it auto-allows edits; at Manual they are held) - but the decision in front of you is the same one Copilot presents, even where the option spelling varies by tool.

One work session, played back with its permission policy x-rayed beside it. Every approve? prompt is an edit to that policy, not a yes/no - watch the ledger on the right, and when playback pauses, the prompt is yours.

agent session - orders-api

agent cli · new session · repo: orders-api

what runs without asking

The prompt wears different clothes across tools - allow/always/deny buttons, allow rules in a settings file, approval modes, sandbox flags - but underneath every one is this same ledger: a standing policy you edit one decision at a time. Grants sized to an exact command age well. Grants sized to a wildcard, approved under fatigue, are how an agent ends up with more rope than anyone remembers giving it.

One more idea lives in the widget that the prose has not named: grants are sized. “Once” answers this run and leaves nothing standing; a narrow standing grant (an allowlist entry for one command pattern) keeps deciding for you within its pattern; a broad wildcard keeps deciding everywhere it matches. Standing grants are convenient precisely because they stop the prompts - which is why their size deserves the same read as the command itself.

Keep it - here, especially

Once Copilot has been right a few times, it is tempting to reach for Allow all and skip the interruptions. On your own app, maybe. On the shared library, the checkpoint is your friend - keep it. The cost is a few seconds of reading per consequential action; the thing it buys is the chance to catch the one command that would have broken twelve services before it ran. That trade is lopsided in your favor, and it is exactly the trade the manual default exists to make.

Try it

Trigger a checkpoint by letting Copilot run a terminal command in the Agent role - at the manual default, commands and edits are held, whatever they change. Read all three items in the checkpoint dialog before you approve: what it runs, why now, and whether you could undo it. Then try the same task at a looser permission level and notice which prompts disappear.

So why was Manual right here and Allow all right one repo over? That is the judgment the next page names. Match autonomy to blast radius.