How to stop Claude Code permission prompts in .NET

Claude Code used to ask for approval on every single action. If you left it running, you could come back to find it stuck waiting on a prompt. Auto mode has changed that, but it means AI decides what's safe in your project. I'll show you how to add ask and deny rules to a .NET project, and which settings file wins when the rules conflict.

Skipping permissions in Claude Code

To stop the prompts, you can start Claude Code with the --dangerously-skip-permissions parameter. All the prompts disappear.

But this gives Claude full permission to use your machine. It can delete any file it wants to, run any command and even change files in other folders. It still asks before deleting the system root or your home directory, but most commands go straight through. That's far too much access just to save some clicks.

How auto mode works

In August 2026, auto mode became the default in Claude Code for Pro, Max and Team plans. It's a middle ground between approving every single action and approving nothing.

A second model, called a classifier, reviews actions such as shell commands and web requests before they run. It gives a second opinion. File edits in your project and read only commands run without a check.

Riskier actions get blocked. These include throwing away uncommitted changes, deleting files that existed before the session and deploying to production.

It's a better middle ground than skipping permissions altogether. But it means you're giving AI the decision on what is safe and what is dangerous.

Where auto mode falls short

Auto mode looks for actions that are dangerous. The two problems I had weren't dangerous, but they were annoying and disruptive.

Writing an EF Core migration by hand

I asked Claude Code to add an EF Core migration. Rather than using the command line, it wrote the migration file by hand.

When I reviewed the code, everything looked fine. But when I went to update the database, I got an error. I deleted the migration and created it myself by running the command.

Running the app in the background

I was using Claude Code to make some CSS changes to a .NET MVC website. Whilst it was making those changes, it was running the website in the background.

When I tried to start the website in Visual Studio, I got an error saying that it was already running. Nothing went wrong, but it was unnerving to think that an AI agent was running my website. I wasn't sure it would stop running it when I asked it to.

Adding permissions to a .NET project

To add permissions to your project, create a settings.json file in the .claude folder at the root of your project.

The ask list contains the commands Claude Code must ask permission for before it runs them. This includes adding an EF Core migration through the command line and running the application.

The deny list contains what Claude Code is not allowed to do. This includes editing any file in the Migrations folder, which stops it writing a migration by hand, and updating the database through the EF Core command.

{
	"permissions": {
		"ask": [
			"Bash(dotnet ef migrations add *)",
			"Bash(dotnet run *)",
			"Bash(dotnet watch *)",
			"Bash(run_in_background:true)"
		],
		"deny": [
			"Edit(**/Migrations/**)",
			"Bash(dotnet ef database update *)"
		]
	}
}

Testing the ask rules

I asked Claude Code to add an EF Core migration. It asked for permission to run the dotnet ef migrations add command, with a message saying that the ask rule Bash(dotnet ef migrations add *) overrides auto mode for this command. I allowed it.

The project's CLAUDE.md file asks Claude Code to run the application after every change to check it still works. When it tried to do this, it asked for permission first.

This shows that the rules in your settings file come first. An ask rule will still prompt you, even in auto mode.

Testing the deny rules

Next, I asked Claude Code to update the database with the migration. As this command is in the deny list, it blocked the request.

Claude Code explained that it couldn't run the command because .claude/settings.json has Bash(dotnet ef database update *) in its deny list.

It gave two ways to update the database:

• Run it yourself.

• Take Bash(dotnet ef database update *) out of the deny list, or move it to the ask list so you approve each run.

Which settings file takes priority

Claude Code reads three types of settings file:

• settings.local.json lives in the .claude folder at the root of your project. It usually takes priority over settings.json.

• settings.json lives in the same folder, and applies to the project.

• settings.json in the .claude folder of your home directory applies to every project. It usually has the lowest priority.

But this is not the case with permissions.

A deny rule always wins

When I was writing this article, I found that Claude Code couldn't run the application. When I investigated, I found a deny rule for running the application in the settings.json file in my home directory. It was left over from testing the permissions earlier.

{
	"permissions": {
		"deny": [
			"Bash(dotnet run *)"
		]
	},
	...
}

Claude Code said it couldn't start the app because it was refused permission both times it tried dotnet run, so it stopped rather than trying other ways around the block. It gave two options:

• Run it yourself

• Add the command to permissions.allow in .claude/settings.json or settings.local.json, for example "Bash(dotnet run:*)".

As a deny rule wins, I wasn't sure why it recommended the second option, but I tried it. I moved Bash(dotnet run *) to the allow list in the project's settings.json file.

{
	"permissions": {
		"allow": [
			"Bash(dotnet run *)"
		],
		"ask": [
			"Bash(dotnet ef migrations add *)",
			"Bash(dotnet watch *)",
			"Bash(run_in_background:true)"
		],
		"deny": [
			"Edit(**/Migrations/**)",
			"Bash(dotnet ef database update *)"
		]
	}
}

Claude Code still couldn't run the application. It said dotnet run was denied again, so it didn't retry.

I asked it why it was denied and to check all the settings files. It found the deny rule in ~/.claude/settings.json, the user settings file in my home directory. It explained that Claude Code combines the permission rules from every settings file, and that a deny rule always wins over ask and allow, whichever file it's in. So the allow rule in the project file couldn't override the deny in the user file.

It also pointed out that my settings.local.json file had dotnet run in its ask list. When an ask rule and an allow rule both match, the ask rule wins. So even after removing the deny rule, Claude Code would still prompt before running the app, unless the ask rule was removed from the local file as well.

Viewing all the permissions in a project

To see all the permissions in your project, run the /permissions command in Claude Code. Each section lists its permissions. The deny section lists every deny rule for the project, and anything in there won't be allowed to run.

Why permissions matter

Before auto mode became the default, I would regularly start Claude Code with the --dangerously-skip-permissions parameter. But I now realise how dangerous that is. You're giving an AI agent full control over your machine.

I think this is one of the reasons businesses are cautious about using AI. They don't know how much access they're giving to AI agents. As they learn more, they will gradually give them more permissions. Setting your own ask and deny rules means you decide where that line is, rather than leaving it to AI.

Watch the video

Watch the video where I show you how to add ask and deny rules to a .NET project in Claude Code, how they work with auto mode, and why a deny rule always wins, whichever settings file it's in.