Claude Code Desktop should honor managed-settings.json for all permissions

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/24433
2. https://github.com/anthropics/claude-code/issues/24381
3. https://github.com/anthropics/claude-code/issues/29026

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Right now the desktop app isn't viable to use for our team because our managed settings do not apply there. This is a really frustrating gap in the experience right now.

Hooks are also not honored in Desktop — PreToolUse hooks ignored entirely

Adding to this issue: it's not just permissions that don't persist in Desktop — hooks configured in ~/.claude/settings.json are completely ignored by Claude Code Desktop.

Setup

I have a PreToolUse hook in ~/.claude/settings.json that catches destructive commands (rm, del, rmdir, Remove-Item) and forces a confirmation prompt:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python ~/.claude/hooks/check_destructive.py"
          }
        ]
      }
    ]
  }
}

CLI: Hook works correctly

● Bash(rm "...file.pdf")
  ⎿  Running…
Hook PreToolUse:Bash requires confirmation for this command:
Delete command 'rm' detected — requires your confirmation. [settings]
Do you want to proceed?
> 1. Yes
  2. No

Desktop: Hook completely ignored

In Claude Code Desktop (Windows 10), the same rm command executes without any hook intervention. Claude only asks for confirmation because CLAUDE.md contains a rule about delete commands — this is model-level compliance, not technical enforcement. When the user confirms, rm runs immediately with no hook check.

Reproduction steps:

1. Configure the PreToolUse hook in ~/.claude/settings.json as shown above
2. Verify hook works in CLI (rm triggers confirmation prompt with "Hook PreToolUse:Bash requires confirmation")
3. Open Claude Code Desktop on the same machine
4. Ask Claude to create a temporary file and then delete it
5. Observe: rm executes without hook intervention — no "Hook PreToolUse:Bash" message appears

Tested with

• Claude Code v2.1.74
• Windows 10, Git Bash (MINGW64) used internally
• Hook file: ~/.claude/hooks/check_destructive.py
• Settings: ~/.claude/settings.json with hooks.PreToolUse configured
• Claude Code Desktop (Windows)

Impact

This means Desktop users have no reliable way to enforce safety rules for destructive commands. The only protection is CLAUDE.md rules, which are model-level and can be forgotten after compaction or in long sessions. This is especially concerning for non-developer users who rely on Claude Code for automation tasks and cannot easily audit every command.

Suggestion

Desktop should load and enforce hooks from ~/.claude/settings.json (and .claude/settings.json) the same way the CLI does. Hooks are the recommended approach for permission control since v2.0, and they should work consistently across all interfaces.

Still experiencing this on the desktop app (macOS, Opus 4.6, March 2026). bypassPermissions set at user, project, and worktree levels -- all correctly formatted, all ignored. Every Bash, Edit, Write, and WebSearch call prompts. This has persisted for months across dozens of sessions.

I am a non-developer business user who relies on Claude Code via the desktop app for daily email triage and project management (~30+ tool calls per morning routine). The CLI flag workaround is not viable because the desktop app has no way to pass --dangerously-skip-permissions.

This is a significant workflow blocker. Filed a detailed standalone report at #38662.

This is impacting us also. We set forceLoginOrgUUID in endpoint managed settings through Jamf. We want it to apply to Claude Desktop as well, but it seems like that key isn't supported there.

This is impacting us also. We set forceLoginOrgUUID in endpoint managed settings through Jamf. We want it to apply to Claude Desktop as well, but it seems like that key isn't supported there.

Create a new profile > Payload for the profile must be com.anthropic.claudefordesktop

<key>forceLoginOrgUUID</key>
<string>xxx</string>

This seems all kinds of strange, but how many different locations are there for settings? A Jamf Configuration Profile for com.anthropic.claudefordesktop doesn't seem to get put anywhere on deployment? the actual plist in preferences for the desktop app features an entirely different schema.

~/Library/Application Support/Claude contains a managed-settings.json....but where did this come from? It doesn't contain the same the settings as what is in JAMF.

/Library/Application Support/Claude also contains a managed-settings.json I put there via script, and it seems to be the one that is properly enforced, at least for CLI Claude Code.

I'm attempting to manage Claude Desktop and Claude Code CLI and I'm not entirely sure how to get Desktop managed-settings.json in the right place. (It seems like a Custom Configuration file isn't the answer...?)

This seems all kinds of strange, but how many different locations are there for settings? A Jamf Configuration Profile for com.anthropic.claudefordesktop doesn't seem to get put anywhere on deployment? the actual plist in preferences for the desktop app features an entirely different schema. ~/Library/Application Support/Claude contains a managed-settings.json....but where did this come from? It doesn't contain the same the settings as what is in JAMF. /Library/Application Support/Claude also contains a managed-settings.json I put there via script, and it seems to be the one that is properly enforced, at least for CLI Claude Code. I'm attempting to manage Claude Desktop and Claude Code CLI and I'm not entirely sure how to get Desktop managed-settings.json in the right place. (It seems like a Custom Configuration file isn't the answer...?)

My script puts claude code managed settings in "/Library/Application Support/ClaudeCode" which works for us.

@klssland thanks! They don't document that it's supported on the Desktop MDM options page, so I appreciate you checking that. Anthropic folks, it might be worth a docs update.

@oneforkshort FYI if you set the managed settings (desktop app options are here, and Claude code options are as discussed here) in a Jamf Configuration Profile then as far as I can tell, it works properly (and of course wouldn't store an actual file anywhere; it'd just be in the managed profiles).

For local deployed MCPs in desktop app via claude_desktop_config.json there is still no way to set per tool level permission team wide like you can do it via managed-settings.json in claude code.

This is so annoying for company wide rollouts.

Cowork is now reading manged-settings.json (which breaks our Claude Code using Vertex AI MDM deployment.
You need to support CoWork and Claude Code with Vertex AI to work together and not break each other.
Is seems that any value in "_apiKeyHelper_" is breaking CoWork. In addition, OTLP settings in managed-settings.json is overwriting OTLP config in CoWork UI (or when not configured at all).

We need to be able to instruct CoWork to ignore the managed-settings.json completely as we need different settings for claude code (via vertex ai) and CoWork.

@ssalzman-kobold this sounds like a strong use case for an external deny layer.

I am building Agent_Sudo, which can sit in front of agent/MCP tool execution and enforce policy even when the agent runtime is otherwise permissive. The model is: tools still route through a gateway, and the gateway can hard-deny specific tools/actions, require approval for sensitive calls, or allow scoped delegations with expiry and audit logs.

Your issue sounds like “fast mode is useful, but some tools should never be callable in that mode.” Is that the right read?

If yes, I would be interested in what deny rules you would want first: by tool name, command pattern, path/resource, operation type, or managed settings source.

Its actually quite unbelievable that Anthropic is taking so long to have Claude Code on Desktop respect managed-settings. How do they expect enterprise deployments and AI gateway enforcement to work for claude desktop without this!?

Amen to this I'm trying to create an agent-guardrails plugin and its seems impossible...the hooks even show up in the plugin but never seem to actually fire.

The managed-settings gap is also an auditability gap, not just a UX gap. If Desktop ignores the same policy source the CLI enforces, the organization cannot later answer a basic question: which policy version authorized this tool action?

For enterprise rollout, I would expect every Desktop tool decision to be able to emit a small enforcement receipt: settings source loaded, policy version/hash, permission rule matched, tool/action requested, final allow/deny/ask result, and whether a hook or managed override participated. That receipt does not need to expose secrets or user data, but it gives admins something verifiable when investigating why a tool ran.

This is the same boundary AgentFolio/SATP-style trust systems care about: trust should attach to the action plus the policy evidence, not just to the agent identity or the user saying they approved prompts sometime earlier. Consistent managed-settings enforcement across CLI/Desktop is what makes those receipts comparable across surfaces.

Someone make this happen. I want to update programatically the .mcpb on my organization with a CD workflow, and every connected user as well.

Its actually quite unbelievable that Anthropic is taking so long to have Claude Code on Desktop respect managed-settings. How do they expect enterprise deployments and AI gateway enforcement to work for claude desktop without this!?

I usually notify the users by sending an e-mail and add a field 'notes' on the ping tool to inform any change for the users.