Claude Permissions - This will change the way you use Claude

Timestamps

• 00:00 - Intro
• 01:46 - Permission Options
• 04:12 - Classifier Blocks
• 05:40 - Bypass Permissions
• 09:52 - CLIs
• 13:22 - What's Next?

These are the notes for the permissions video. The exact commands and the Docker isolation setup are all here so you can follow along.

The problem

You've probably been in the spot where Claude Code asks permission for the most basic stuff. It's irritating, it breaks your flow, and it means you can't run anything autonomously, you're checking in every couple minutes to see if it's waiting on you. Great for beginners, gets old fast.

Allow and deny rules are the next step, but they don't cover everything that can come up, so they still block really productive work. If I want an agent to run for a long stretch on its own, I need more than that.

Claude has more permission modes than you've probably used. Getting past this blocker, Claude not being able to run on its own, is the first step to building out large chunks of an app. So the goal is to give Claude the freedom to run autonomously without letting it destroy your system, your personal life, or your production servers.

The modes

When you run Claude, the permission mode shows at the bottom. Out of the box you get read-only, and you approve each edit. Toggle modes with Shift+Tab.

The mode that reviews every action is called manual in the CLI. Shift-tabbing you'll probably see auto mode show up, but you won't see bypass permissions, that's not there by default. And if you don't even see auto mode, you have to launch into it:

claude --permission-mode auto

There are requirements for auto mode to be available, and they'll change over time, so check the permissions docs rather than trusting a specific list from any one video.

Saving permissions between sessions

When you say "yes" or "allow all edits during this session," that only lasts for the session. Close Claude and reopen, and they're gone.

If you want to keep them but dump your context, use:

/clear

That wipes the conversation but keeps the permissions. To keep them for good, write them down permanently in your settings.

Those allow and deny rules are boundaries. For example, you can block git reset --hard. But treat them as accident prevention, not a wall against a malicious AI, it could find a way around a specific command. They stop the "whoops" moments, which is usually what you need.

Auto mode

Auto mode allows most things by default. Under the hood a separate classifier model reviews actions before they run and blocks anything that escalates beyond a plain request. Anything dangerous still gets a prompt, and so do command substitutions, backticks, and process substitutions. Mostly it just nudges Claude to keep working instead of stopping to ask clarifying questions.

What auto mode blocks

By default it trusts your working directory and the remotes that were configured when the session started. A remote you add or repoint mid-session (git remote add, git remote set-url) is NOT trusted, and everything else is treated as external until you set up trusted infrastructure.

So the risky stuff is blocked, roughly:

• downloading and executing code (curl piped into bash)
• sending sensitive data to external endpoints
• production deploys and migrations
• mass deletion on cloud storage
• granting IAM or repo permissions
• force pushes (which can drift your migrations away from your actual database structure)

There's a full list in the docs. The point is it lets you do the safe things and blocks what's likely to hurt. I ran a full feature build in auto mode with zero prompts and no issues. That's your first real unlock.

Bypass permissions

The next step is launching with dangerously skip permissions. It's called --dangerously-skip-permissions for a reason, so pay attention, this is the one that can delete your production database and go "oopsies, my bad." With it on, Claude will do whatever, post data, run anything risky, because you told it it could.

So when would you want this? I just assume the worst case. If the AI went off the rails and tried to delete all my code or wreck the project, what could it actually do? If the answer is "a lot," then it's not set up right.

The fix is to isolate it. In the video I'm running bypass on this machine without a container, pushing the limits, but this is mostly a recording machine with nothing sensitive on it. Even then there's real risk, because I'm connected to a live production environment through MCP, working with production data for my own site.

Isolating in Docker

Best move is to have Claude build the isolation for you:

create any Docker files (Dockerfile, docker compose), whatever you see necessary for my project.

On one of my node projects I tied it to npm run cc, then had cc1, cc2, cc3 for running multiple instances that share the same repo and the same Claude config. That sharing is intentional. The catch is the config lives both inside and outside the container, so you have to make sure nothing sensitive is in it. The big thing to pull out is any MCP connections, since those tie straight to production data.

The setup I described to it: multiple instances share the same config and login at the REPO level, so the container doesn't have to deal with it. The container just mounts the directory, and you can run inside or outside of it.

When it finished it gave me a docker compose build and a launch command, and I had it boil that down to a single command. Trust the folder, and you're in with bypass permissions on. You can read more about compose in the Docker docs.

Keeping secrets out of the container

Words of wisdom: don't put anything sensitive in the repo. No production environment variables. Use testing ones instead.

Take Stripe. Keep the production keys out and use local/test keys for development. Then you can give Claude free rein over those, because there's no risk if it touches them. For databases, run them as separate containers that the Claude instances share, or let each one manage its own.

Same idea for CLIs. If you've got gh for GitHub, or Vercel, or anything wired to production, keep it out of the repo. SDK credentials usually live at the user level anyway (something like ~/.aws/credentials), which works out great, because inside the container Claude can't see them. It can't push, pull, or take over your repos. Not that it would, but I'd rather it just not have access.

So the workflow is: code INSIDE the container, then commit and push from OUTSIDE, where your git config actually lives. The container is basically a dummy working on the mounted code with no git credentials of its own.

To sanity check, I asked the running instance to look at my GitHub and AWS config, and it came back with "neither CLI is installed in this environment," which is exactly what you want.

The MCP still connected inside

One thing to watch. Inside the container I still had access to the Course Catalyst MCP, which means I could still destroy all my real work. That's the biggest one to figure out how to split out.

A couple options. You can strip the MCP connections out of the config the container uses. Or you can add a pre-tool-use hook that blocks execution of any MCP commands. Just know the hook stops Claude from invoking the tools, but the container is still logged in to your account, so it's not a full fix.

And a small tip: if you just want to ask a question, tell it "don't code." That keeps it from running off and building something when all you wanted was an answer.

Remote control

You can also drive this from your phone. Enable remote control (the RC command), it connects up to Claude, and then anything you type on your phone shows up in the session after a second. I do this all the time.

What's next

That's the two unlocks, auto mode and bypass permissions inside an isolated container. The details of how I structure my isolated containers for real projects go deeper than one video can cover, so I'll keep sharing those, and it's a big part of the Agentic AI course where we take this and actually build and deploy an app end to end.