[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

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] 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.*