Configuring Claude Code Permissions for .NET Development

How should you configure Claude Code permissions so a coding agent can build and test a .NET project without gaining database or publish authority? This guide explains the documented rule order, settings scopes, wildcard risks, and boundaries for migrations and deployments. It is worth reading before you run agents unattended on .NET repositories.

Key points

• Rule evaluation runs deny, then ask, then allow; a matching deny or ask is not overridden by a narrower allow.
• Keep dotnet test, build, and publish behind ask, and avoid pre-approving broad families like Bash(dotnet *).
• Put shared baseline rules in .claude/settings.json and personal tweaks in .claude/settings.local.json; never store tokens in either.
• Generating an EF Core migration is different from applying it, and creating build output is different from deploying it.
• Remove production credentials from development runners instead of relying on prompts or CLAUDE.md alone.
• When a command is blocked, check the /permissions view and the exact tool name, since Bash rules do not cover PowerShell calls.

Claude Code permissions decide which tools a coding agent can run without asking, and the author argues that treating every dotnet command as one broad family is a mistake. Reading source, editing files, running tests, applying migrations, and publishing each have different effects, so each should be judged by the resource it touches and the credentials it needs.

The guide walks through the documented rule order of deny, ask, and allow, the settings scopes from shared project files up to managed policy, and the limits of wildcard matching. It stresses that CLAUDE.md is guidance rather than enforcement, and that headless runs load repository hooks and MCP configuration without the interactive trust dialogs. Its main point is that removing database and deployment credentials from a runner is a stronger control than any prompt.

Real-world use

• Letting Claude Code edit an ASP.NET Core endpoint and run dotnet test while blocking database updates and publish commands.
• Generating a headless summary of a domain folder on a shared CI runner, limited to the Read tool.
• Reviewing inherited team settings before allowing unattended EF Core model work.

Why it matters

A .NET team should treat Claude Code permission rules as one layer alongside instructions, runner credentials, and server-side authorization. An approved dotnet test never implies consent to migrate a production database or publish a release.

Related stories

• .NET 8 and 9 End of Support: A Deployment-First Migration ChecklistDVDEV Community: #dotnet2 d ago
• Publish Visual Studio Marketplace extensions securely with Trusted PublishingMDMicrosoft for Developers Blog5 d ago
• EF Core Migrations: Why Bundles Beat Startup MigrateAsync()MLMostly Lucid (Scott Galloway)6 d ago