A coding agent can run commands on your machine. We need to decide what it may do on its own and which actions should wait for our approval. We'll start with the permission prompt, then look at permission modes and standing rules. We'll also separate approvals from access limits, and see how checkpoints and isolation let you reduce interruptions where mistakes are easier to contain and recover from.
Let's start with that permission prompt. Suppose you ask the agent to clean up the build and redeploy the project.
To carry that out, the agent decides to run a shell command. This one removes the dist folder, and then runs the deploy script.
The command shown needs approval before it runs. You can allow it once, save a rule for similar commands when that option is offered, or refuse it. Read what an always-allow choice covers before selecting it.
The agent is asking to execute the command on your machine. Removing the build folder and running the deploy script will have real effects if you approve it. Use this pause to read the command and decide whether those effects match what you asked for.
A permission prompt lets you review an action before it runs. Read the requested action before approving it. Deleting files can be difficult or impossible to undo, and deployment can change a running service. The prompt gives you a chance to catch an unwanted action before it runs.
Claude Code lets you set policies for repeated actions. As we saw in week one, Shift Tab cycles through the available permission modes. These include manual, accept edits, plan, and, when available, auto. Check the mode shown in your session, since the available cycle depends on the setup. The mode sets the session's general approval behavior. Standing rules let you decide recurring cases in advance, and save those decisions for the sessions covered by that settings file.
Standing rules live in the settings file. An allow rule permits matching commands without the usual prompt. The examples are npm test and git status. Before allowing npm test, check what the project's test script runs, since the command name alone does not make a script safe. A deny rule blocks matching commands, such as the recursive-remove and force-push forms shown here. Rules apply in the scope where you save them, for example one project or your user settings. They match command forms, so a short example rule is not a complete ban on every way to delete files or rewrite history.
Claude Code checks permission rules in the order deny, ask, then allow. A matching deny rule blocks the command even if an ask or allow rule also matches. If there is no deny match, an ask match requires a prompt. If neither matches, an allow match permits the command. When no rule matches, the permission mode and other checks determine what happens. An uncovered command does not always produce a prompt.
Deny takes precedence over ask, and ask over allow. This lets you keep a matching command blocked even when a broader allow rule also matches it. The rule must actually match, so review its scope and use access restrictions as well when you need to contain damage.
There are two decisions here that are easy to confuse: what an action can reach, and whether it needs approval before it runs. The first is access. A read-only setup lets the agent inspect files without changing them. A project-limited setup may allow edits only in the project. A much broader setup can reach whatever the operating-system account and available credentials permit, potentially across the machine.
The second is oversight: when the agent stops to ask. You might require frequent approvals, allow routine work inside an access boundary and ask before going outside it, or arrange a run with no interactive approvals. These describe approval policies, not how much access the process has.
You can combine broad access with frequent approval prompts, or restricted access with permission to act freely inside the boundary. The first depends on you catching a bad action. The second limits what an allowed action can affect. Claude Code's permission modes and rules handle approvals. Its sandbox settings can restrict filesystem and network access for commands. Other tools may present these controls differently, but it is useful to ask both questions separately.
Claude Code has a flag called dash dash dangerously skip permissions. It enables a mode that bypasses the usual approval prompts and checks.
With that flag on, ordinary commands can run without your approval, including destructive commands. Do not count on a prompt to catch a bad command before it happens. The flag does not give you a sandbox. If you want to limit what the agent can reach, you must set that up separately. An unwanted command can come from a bad guess by the model or from a prompt injection, an instruction smuggled into something it reads, as we saw in the introduction. Without an approval prompt in the way, that command can run before you notice it.
Use this flag only in an isolated, disposable environment where a wrong command cannot reach important files, keys, or services. A container or virtual machine can provide that separation if you have not exposed sensitive host folders or credentials to it. Keep the normal approval controls on when working directly on your laptop. Saving a few prompts is not a reason to give an unchecked command access to your everyday files.
Start with strict permissions and read the prompts. Before relaxing them for a task, arrange a way to recover from the kinds of mistakes that task could produce. Before the agent edits the project, review and commit the working version you want to preserve. As in the first Git lesson, select the file versions that belong in that commit and check that the files you need are included. Keep the commit's identifier so you can compare later changes with this saved starting point.
With that version saved, allow more routine work where you can recover from mistakes. You might use accept edits for changes inside the project, or grant access to one additional folder the task needs. Make the change where the possible damage is limited, and continue to review the result.
Press Escape to stop the current response, then inspect the changes. Stopping the agent does not undo its edits. Slash rewind can restore file-tool edits that Claude Code captured, as we saw in the session lesson. In the Git lesson, we restored a tracked file from a saved checkpoint after checking which edits would be discarded. For a different recovery situation, identify the version and work that you wish to keep, then ask the agent to explain the appropriate operation before running it.
These recovery tools do not undo every shell command or external effect. So far we have considered files that git recorded, which can be restored while the saved versions remain available. An agent with broader access can also damage the recovery mechanism itself. It can rewrite or delete git history, push harmful changes to a remote if its credentials allow that, or delete the whole project. The possible damage depends on the files, services, and credentials its tools can reach.
Think beyond recovering the current project. If the machine were wiped, you would need another copy of all your important data. Keep backups somewhere the agent cannot modify or delete. That is good practice anyway, because malware and ransomware can wipe a machine just as thoroughly as a careless agent can. Later in the course we will see how to set up an isolated machine for the agent with very little on it, which makes this much easier, and we will come back to security in more depth.
Recoverability is what buys you speed. Loosen the limits in proportion to how easily you can undo a mistake. That works for edits git recorded. Keep tighter control over actions a local commit cannot reverse, like publishing something or deleting data that lives elsewhere. Git helps restore recorded files, while a sandbox limits what a command can reach. Using both can reduce risk and let routine work proceed with fewer interruptions.
This diagram represents how much approval you require as a dial you can adjust. At the left end, you review actions frequently before they run. Frequent prompts give you more opportunities to catch a mistake, but they take your time. They do not guarantee safety, because you can still approve a damaging command.
At the right end, actions run without waiting for your approval. This reduces interruptions, but a mistake can proceed further before you see it. How much damage it can do still depends on its access.
You can choose a setting between these ends and change it as the task changes. Start strict while you learn what the agent is asking to do.
Reduce approval prompts for work where you have made recovery straightforward or restricted the agent's access. A clean commit helps with tracked file edits, while a properly configured container or sandbox can limit what commands reach. Return to stricter approvals for unfamiliar code and for actions you cannot easily undo. Check those actions before they run.
To choose a setting, ask what the agent's current access lets it damage and what recovering from that damage would involve. Recovering a recorded file may be simple. Exposing a secret or changing a remote service may not be reversible. Isolation reduces what the agent can reach, so the more it does without asking, the more carefully you should limit the possible harm.
There is no one setting for every task. Begin with strict approvals, then loosen them for specific work whose effects you understand and can contain. Keep checking the work as you do this. Successful earlier tasks do not make an irreversible action safe, and a checkpoint only helps with the kinds of changes it records.
Everything so far assumes that you can read a permission prompt and judge it. In practice, that is getting harder. Agents often write long commands that chain many steps with double ampersands, and pipe the output of one program into the next. Here is a prompt of that kind. In one line, it installs packages, runs the type checker and filters its output, clears a build folder, switches branches, and builds again for release.
One step in the middle deserves a closer look. It runs rm dash r f on everything inside the folder named by the build dir variable. If that variable happens to be empty, the path becomes slash star. The command then tries to delete everything it can reach from the root of the disk. Spotting this takes careful reading, and the prompt looks just like the many harmless ones before it.
When almost every prompt is harmless, people stop reading them closely. This is called approval fatigue. Anthropic reports that Claude Code users approve 93 percent of permission prompts. In a study Anthropic published in August 2026, one prompt in a paid coding task was swapped for a clearly dangerous command. Only 13.6 percent of the 1,053 testers blocked it. Early in a session, about 17 percent caught it. After fifty or more earlier prompts, only about 5 percent did.
This is one reason Claude Code added auto mode, which is now its default mode. In auto mode, a separate classifier model reviews each action before it runs and blocks the ones that look dangerous. In the same study, auto mode blocked 89 percent of the swapped commands. That is far better than the testers did, but it is not a guarantee. Anthropic's own measurements found that the classifier missed 17 percent of real cases where the agent went further than the user asked. So relying on auto mode means relying on another model's judgment, and that judgment can be wrong.
So take the advice in this video as the current state of a young field. The tools, their defaults, and the recommended practice are changing quickly, and keeping coding agents secure is still an open problem. When a command is too long to check, you can deny it, and ask the agent to run the steps one at a time or to explain each part. What holds up is the structure we used. Limit what the agent can reach, and keep a way to recover.
You are deciding both access and oversight. Access is what an action can reach, and oversight is when it needs your approval. In Claude Code, use modes and rules for approvals, and consider sandbox settings and the surrounding environment for access limits.
Start strict and make a checkpoint before allowing more routine editing. Commit the version you want to preserve, then loosen approvals only for work whose possible effects you can contain and recover from.
Return to closer approval when the task reaches unfamiliar code, sensitive data, or an action that is hard to undo. A saved code version does not reverse everything a command can do. These choices let you give the agent useful room to work while keeping its possible mistakes manageable. Each time you start a task, check both what it can reach and what it can do without asking.