[BUG] macOS plist managed settings no longer override user settings in v2.1.80
Status Fixed / completed
Reported on v2.1.79
Maintainer reply None cached
Activity 5 comments · opened Mar 20, 2026 · closed Mar 27, 2026
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?
Settings that are set in the plist (as managed settings) no longer override and take effect over the other user/project/local settings. This worked in 2.1.79 but stopped working in 2.1.80.
On top of that, some settings will get locked into the wrong position. For example, if plist has sandbox.enabled = true, but user settings has sandbox.enabled = false, what ends up is that sandbox is off but yet cannot be turned on by the user with /sandbox command.
What Should Happen?
Managed settings (whether plist or json) cannot be overridden by user/project/local settings.
Error Messages/Logs
2026-03-20T15:50:52.159Z [DEBUG] MDM settings load completed in 3ms
2026-03-20T15:50:52.159Z [DEBUG] MDM settings found: env, sandbox, companyAnnouncements, PayloadUUIDSteps to Reproduce
- Install a configuration profile (
.mobileconfig) into macOS with a setting, such as sandbox.enabled = true. - Configure in your user settings that sandbox.enabled = false
- Start up Claude Code, observe that sandbox is off, there is no message upon startup notifying of the sandbox on
- Type in
/sandboxinto Claude Code REPL but do not press enter, observe the message◯ sandbox disabled (managed) (⏎ to configure) - Press enter, observe that it fails because the setting is locked by managed settings
Error: Sandbox settings are overridden by a higher-priority configuration and cannot be changed locally.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.79
Claude Code Version
2.1.80 (Claude Code)
Platform
Other
Operating System
macOS
Terminal/Shell
iTerm2
Additional Information
_No response_
5 Comments
I could not get Opus 4.6 to debug this, but after I manually bisected down to a specific offending section that was triggering the settings read before the plist settings were read, I figured out that it was because while constructing the Commander command for
remote-controland determining whether it's hidden, in v2.1.79 it was only reading a feature flag but in v2.1.80 the settings are being read to check forapiKeyHelper, while at that point the cache for the plist managed settings hasn't been populated yet as the Commander preAction that reads the plist hasn't had a chance to run yet, and ends up producing and caching the wrong settings.Looking at the v2.1.80 release notes this is likely a regression arising from:
This is still present in v2.1.81.
This is a problem for us, now that plists isn't working for enterprise use case.
This seems to be fixed in v2.1.83.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.