claude-code - 💡(How to fix) Fix [BUG] `/permissions` reports success when adding new Allow rules and writeable workspace dirs that managed policy forbids (misleading UI, not enforced; no privilege escalation)

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Summary

With an enterprise/admin managed policy active, /permissions lets a runtime user add entries to the Allow rule list and the Workspace directory list and reports success (e.g. Added directory / to workspace for this session), even though allowManagedPermissionRulesOnly and denyWorkspaceModification declare these settings non-overridable. The edits persist visibly in the session UI but are never written to the settings files and are not enforced — the dialog is misleading.

Environment

• Claude Code with an admin managed-settings.json (/etc/claude-code/managed-settings.json).
• Relevant managed flags:
  • "allowManagedPermissionRulesOnly": true
  • "denyWorkspaceModification": true
  • workspace.denyPaths: ["/"]
  • sandbox.filesystem.denyWrite: ["/"]

Actual

/permissions accepts the additions, prints success messages, and keeps them displayed in the session UI — implying the allow-list / workspace was changed.

Enforcement was NOT bypassed (scoping)

• Writing outside the allowed workspace (/bypass-probe-outside-workspace.txt) → EACCES: permission denied, despite / having been "added" to the workspace.
• ~/.claude/settings.json and .claude/settings.local.json were unchanged after the edits — the runtime changes were never written to disk.

This is a UI / feedback defect, not privilege escalation or sandbox escape.

Impact

Low security severity (no actual escalation). Meaningful operator-confusion risk: a user may believe they granted a tool or directory when they did not.

What Should Happen?

Expected

With those managed flags set, /permissions should refuse the additions, or visibly mark them as overridden/locked by managed policy.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce

1. Deploy managed-settings.json with allowManagedPermissionRulesOnly: true, denyWorkspaceModification: true, and workspace.denyPaths: ["/"].
2. Run /permissions.
3. On the Allow tab, add a tool (e.g. WebFetch).
4. On the Workspace tab, add /.
5. Observe each change is reported as applied and remains shown in the dialog for the session.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.165 (Claude Code)

Platform

Other

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Suggested fix

When allowManagedPermissionRulesOnly / denyWorkspaceModification are set, /permissions should disable the corresponding additions and/or show a "locked by managed policy" message instead of reporting success.

Disclosure: drafted with AI assistance (Claude Code). The submitter reproduced the UI behavior; the "enforcement not bypassed" scoping was confirmed via in-session probes (EACCES on out-of-workspace write;
settings files unchanged). Reviewers should still independently confirm.