Settings sources and locks
If a saved setting has no effect, a control is locked, or a configuration file cannot be read, use this page to find the cause and the correct place to change it. Open Settings > Managed policy.
Value precedence
| Source | Responsibility |
|---|---|
| Local managed configuration | Pins settings above enterprise policy and user choices |
| Enforced enterprise policy | Pins settings delivered to the enterprise session above project and user layers |
| Project configuration | Overrides user choices without overriding enforced values |
| User configuration | Stores personal choices |
| Enterprise defaults | Fill unset project and user values without locking user choices |
| Built-in defaults | Supply values absent from the other layers |
The panel displays received policies and their resolved values; it is not an enterprise policy publishing console. Administrators publish through their management system. Precedence determines the displayed value. A lock prevents lower-priority configuration from overriding that value, but does not by itself prove enforcement across every execution path. Check runtime notes for reserved, unenforced, or default-only settings and validate the corresponding feature. See approvals for individual actions and permission rules for rule simulation.
Defaults, locks, and runtime enforcement
A default supplies a value when no higher-priority choice exists. Enterprise defaults sit below user and project configuration, so they provide starting choices. A restriction users must not change belongs in an applicable enforced source, with runtime support checked for that key. An enterprise-supplied value does not by itself prohibit user changes.
A lock identifies an administrator source as the deciding layer. The report also retains other source values to explain why a user-file edit did not become the resolved result. Inspect source and lock state before the key's runtime notes; reading only the edited file misses higher-priority policy.
Some keys are consumed only from governance sources; others depend on running-kernel capabilities. A resolved value does not establish that the current runtime consumes it. Validate both allowed and denied behavior on the target version and actual executor, retaining the results. A screenshot of a lock is not sufficient enforcement evidence.
When several sources define the same setting
The abstract values A, B, and C below illustrate resolution for one key. They are not a configuration file to copy.
| Supplied values | Resolved result | Where to make a change |
|---|---|---|
| Enterprise default A, user B | User B; the enterprise default does not lock it | User choice |
| User B, project C | Project C | Check whether the project override is intentional |
| Enterprise enforced A, user B, project C | Enterprise A, locked | Enterprise policy owner |
| Local managed B, enterprise enforced A | Local managed B, locked | Local administrator source first |
| No source supplies a value | Built-in default | Establish which sources the key supports |
Clearing the user layer removes that layer's choices and lets other sources determine the result. It does not remove enterprise policy or reset every setting to its built-in default. Establish the expected result before resetting an entire layer to change one setting.
Inspect a setting
- Refresh the policy report and inspect configuration-source read status.
- Search effective settings for the key, then inspect its resolved value, source, lock state, and runtime enforcement notes.
- Compare user, project, and administrator values to identify the deciding layer.
- Give the responsible owner the key, source, error, and requested change. Do not edit a lower layer to bypass a lock.
Recover damaged configuration
User and project layers support backup and reset. Confirm the layer first: reset backs up the old file and writes an empty configuration, removing that layer's previous choices from resolution. The application cannot reset the managed layer.
Refresh the report after recovery and verify both file health and the effective setting. After a timeout, refresh to establish the actual outcome before another reset. Configuration recovery does not revoke credentials, restore project files, or change higher-level locks.
When the value is unexpected
Distinguish a source read error, an upper-layer lock, and a change made to the wrong layer. Repair an unreadable source first. Send locked-value changes to the administrator responsible for that layer. For a wrong-layer edit, use the effective source shown in the panel instead of repeatedly resetting other layers.
User settings are stored in <agentDir>/settings.json and project-layer settings in <agentDir>/settings.local.json. Use the actual source paths reported by the panel. Record the backup location and required keys before resetting, restore only confirmed values after repair, and refresh resolution. This page covers the managed settings listed in the panel; it does not assign every application option to this precedence system.
Completion criteria
Confirm the effective value and source, that repaired personal files are readable, and that the affected feature works. A managed lock must be changed by the administrator controlling that source; provide the exact key and reason when requesting help.