Managed settings deny rules from Console not enforced (remote-settings.json)

Bug Description

Managed settings configured in the Anthropic Console under Organizations are synced to ~/.claude/remote-settings.json but the permissions.deny rules are not enforced at runtime. Commands that should be blocked execute successfully.

Reporter

saad@litteraeducation.com

Environment

• Claude Code version: 2.1.71
• Platform: macOS (Darwin 25.3.0, darwin_arm64)
• Auth: Authenticated via corporate/organization account

Managed Settings (configured in Console)

{
  "permissions": {
    "deny": [
      "Bash(aws *)",
      "Bash(kubectl *)",
      "Bash(helm *)",
      "Bash(terraform *)",
      "Bash(terragrunt *)",
      "Bash(eksctl *)",
      "Bash(az *)",
      "Bash(gcloud *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/.aws"]
    }
  }
}

What was synced to ~/.claude/remote-settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Bash(aws *)",
      "Bash(kubectl *)",
      "Bash(helm *)",
      "Bash(terraform *)",
      "Bash(terragrunt *)",
      "Bash(eksctl *)",
      "Bash(az *)",
      "Bash(gcloud *)"
    ],
    "disableBypassPermissionsMode": "disable"
  }
}

Note: The sandbox block configured in Console was NOT synced — only permissions appeared in remote-settings.json.

Local Settings (~/.claude/settings.json)

{
  "permissions": {
    "allow": [
      "Bash(*)",
      "Read(*)",
      "Write(*)",
      "Edit(*)",
      "Glob(*)",
      "Grep(*)",
      "WebSearch",
      "WebFetch"
    ]
  }
}

Reproduction Steps

1. Configure the managed settings JSON above in the Anthropic Console under Organization settings
2. Authenticate Claude Code with a user in that organization
3. Confirm ~/.claude/remote-settings.json contains the deny rules (it does)
4. Run any denied command, e.g., terraform version, kubectl version --client, aws sts get-caller-identity, helm version

Expected Behavior

• All commands matching deny patterns should be blocked and not execute
• Deny rules from managed/remote settings should take precedence over local allow rules
• sandbox.filesystem.denyRead: ["~/.aws"] should prevent reading files in ~/.aws/
• disableBypassPermissionsMode: "disable" should prevent users from bypassing permissions

Actual Behavior

• All denied commands execute successfully (terraform, kubectl, helm, eksctl, aws all ran)
• ~/.aws/config was fully readable (sandbox denyRead not enforced)
• Local Bash(*) allow rule completely overrides the managed deny rules
• The sandbox section from Console config is not present in remote-settings.json at all

Test Results

| Command | Expected | Actual | Result |
|---------|----------|--------|--------|
| terraform version | Denied | Executed (v1.14.6) | FAIL |
| kubectl version --client | Denied | Executed (v1.35.2) | FAIL |
| helm version | Denied | Executed (v3.15.3) | FAIL |
| eksctl version | Denied | Executed (v0.141.0) | FAIL |
| aws sts get-caller-identity | Denied | Executed (failed on creds, not on policy) | FAIL |
| Read ~/.aws/config | Denied | Full file contents returned | FAIL |
| Non-blocked command (echo test) | Allowed | Allowed | PASS |

Impact

This is a security-critical issue. Organizations relying on managed settings to enforce guardrails (e.g., preventing infrastructure commands, blocking access to credential files) have no actual enforcement. Users with local Bash(*) allow rules can bypass all org-level deny policies.