🔐 Chapter 3

Managing MCP permissions in Claude Code

Claude keeps asking permission every time it calls a Spendesk MCP tool? Understand the permission modes, the difference between your own settings and your organization's, and how to unblock yourself for good.

CFOControllerAP ManagerFinance AnalystProcurement6 min read

The problem: a permission prompt on every call

You just installed a skill (see the previous chapter), you ask your first real question, and Claude asks for confirmation before every MCP tool call — spendesk_analyze_spend, then get_payables, then another one. If your request needs several tools, you're clicking "Allow" over and over.

This isn't a bug — it's Claude Code's default behavior, and it's configurable. This chapter explains how, and where the line sits between "you decide" and "your organization decides."

Claude Code's permission modes

Mode	General behavior	Effect on MCP tools
`default`	Asks for confirmation the first time each tool is used; subsequent calls to the same tool go through without asking, but only for the current session	Every MCP tool triggers a fresh prompt the first time it's used in a new session
`acceptEdits`	Auto-approves file edits and common commands within the working directory	MCP tool calls still ask for confirmation
`plan`	Read-only: auto-approves reads, blocks any modification	Read-only MCP tools can run without confirmation; write-capable ones still ask
`auto`	Auto-approves with background safety checks that verify actions align with your request	MCP tools go through, subject to these automatic checks
`dontAsk`	Denies everything by default except what's explicitly pre-approved	An MCP tool that isn't pre-approved never runs
`bypassPermissions`	Skips every confirmation prompt except explicit `ask` rules	MCP tools run with no confirmation at all

The mode is set via defaultMode in a configuration file (see below) — no need to memorize the exact syntax, what matters is knowing this setting exists and what it actually changes for MCP tools.

Unblocking yourself in 10 seconds

On the permission prompt itself, choose "Yes, don't ask again" instead of a plain "Yes". This choice gets saved to .claude/settings.local.json — a personal file, not shared with the rest of your team (unlike .claude/settings.json, which is version-controlled and shared).

The saved rule looks like this:

Prompt to copy

{
  "permissions": {
    "allow": [
      "mcp__<your-spendesk-connector-name>__*"
    ]
  }
}

The exact connector name depends on how it was set up for you — replace <your-spendesk-connector-name> with the real name, visible via the /mcp command. The trailing * allows every tool from that connector in a single rule, instead of approving them one by one.

Tip: no need to hand-edit this file for everyday use — clicking "Yes, don't ask again" does exactly that for you, in the right place.

Personal settings vs. organization settings

Several settings files coexist, with a strict priority order:

Level	Location	Controlled by	Shared?
Managed (organization)	System path, deployed by IT	Your Claude/IT admin	Enforced, you can't override it
Command line	`--settings` flag, one-off	You, for a specific run	No
Project (personal)	`.claude/settings.local.json`	You, on this project	No (not version-controlled)
Project (shared)	`.claude/settings.json`	The team, via Git	Yes (committed)
User (global)	`~/.claude/settings.json`	You, across all your projects	No

Key rule to remember: when rules conflict, a deny always wins over an allow, regardless of which level it's set at. An admin can also lock down the list of allowed MCP servers (allowedMcpServers) or block any personal rule entirely (allowManagedMcpServersOnly).

If the Spendesk MCP doesn't show up in /mcp, or a tool stays blocked despite your own settings: this is almost certainly an organization-level policy, not a personal configuration issue. There's no workaround — the right move is to contact your Claude admin, not to try forcing it open.

Claude.ai and Claude Desktop: a simpler model

On claude.ai and Claude Desktop, approval generally happens at the connector level, not per tool: once the Spendesk MCP connector is approved once, all of its tools become available with no further individual confirmation prompt. This can vary slightly depending on your exact setup (workspace, organization policy) — if in doubt, the most reliable check is your own workspace's connector settings rather than relying solely on this summary.

Best practices for a team rolling out the Spendesk MCP

The Spendesk MCP is almost entirely read-only (exactly one write tool exists, archive_supplier — see the "thinking partner" chapter): for a read-only server, broadly allow-listing it once trust is established is reasonable and removes day-to-day friction.
Never recommend bypassPermissions to a non-technical user — this mode removes every safety net, not just the MCP-related ones.
Stay careful around archive_supplier specifically: it's the only action that actually modifies Spendesk data. An explicit ask rule on that one tool (rather than a broad allow) keeps a human checkpoint exactly where it matters.

Going further

Two commands avoid hand-editing JSON:

/permissions — shows and edits every active rule, along with where it comes from (managed, user, project, session).
/mcp — shows connected MCP servers, their status, and lets you manage authentication.

Once unblocked, the friction is gone for good on this project — head to the next chapter to learn how to phrase your requests well.

← Previous chapter Next chapter →