Manage Glean Tau settings

Use managed settings to control Glean Tau on employee devices. You can restrict approval modes, files, network destinations, and features, or enforce supported app preferences.

Choose where to set a managed value

Choose a delivery method that matches your device management process. The policy format is shared, but each method has a different location and support boundary.

Source	Scope	Deployment guide
macOS configuration profile	A device or a macOS user	Deliver the desktopSettings dictionary
Protected macOS JSON file	A device	Deploy /etc/glean/managed-settings.json
Windows machine registry	A device	Deliver the desktopSettings registry value
Server-managed settings	The authenticated Glean account	Arrange organization policy delivery

Server-managed delivery requires configuration with Glean. Don't assume a self-service Glean Tau policy editor is available in the Admin console.

Understand how Glean Tau picks a value

For ordinary managed preferences on macOS, Glean Tau selects the first valid, permitted value in this order:

1. User configuration profile
2. Device configuration profile
3. Protected managed settings file
4. Server-managed settings
5. Saved user value
6. App default

On Windows, verified machine registry policy takes priority over server-managed settings, then saved user values and app defaults. Windows doesn't use the macOS file location or a user registry key as an admin policy source.

A managed preference shadows the user's saved choice. It doesn't erase that choice. When you remove the override, the next applicable source takes effect. This can reveal the user's saved value.

Managed values are enforced values. The administrator format has no separate section for recommended defaults that users can override. Leave out an ordinary setting to keep it under user control.

For example, server-managed settings turn on automatic update downloads for your organization. A pilot device's configuration profile turns them off. That device uses off, other devices use on, and users can't change either value. If neither source sets the value, users choose it in Settings.

Understand what users see

A managed setting shows a Managed by your organization badge in Settings, and users can't change it there. Glean Tau keeps the user's saved choice underneath the managed value, so the saved choice can apply again after you remove the override.

When policy replaces an approval, reviewer, or sandbox value, users see a notice beside the composer access picker and in Settings → Agent access, such as "Your organization turned the sandbox on." If policy is invalid or can't be refreshed, a banner above the composer explains that agent actions are blocked and names the failing setting and source. The app, chat history, and Settings stay usable. A tool call that policy refuses reports the same reason.

For the settings you can manage, see Use other managed settings.

Understand how security policies combine

Security restrictions from admin sources combine field by field. Denials accumulate, and allowed-value lists narrow each other, so no source can widen what another source allows.

Field	How sources combine
allowedSandboxModes, allowedApprovalPolicies, allowedApprovalsReviewers	Only values that every source allows apply, in the highest-priority source's order. If the lists share no value, the most restrictive value any source lists applies
rules.prefixRules, permissions.filesystem.denyRead	Entries from every source apply
networkAccess, core.authority.fullAccessAllowed	A false value from any source wins
sentinelExtraPolicy	Guidance from every source applies, in priority order. More than 4,000 characters in total blocks agent work
features	Allowlists intersect, and denials combine
shellEnvironmentPolicy	The most restrictive inherit value applies. exclude patterns from every source apply, and includeOnly keeps only patterns every source lists. A false ignoreDefaultExcludes from any source keeps the built-in exclusions

For example, a device profile sets allowedApprovalPolicies to ["untrusted", "on-request"], and server policy sets it to ["untrusted"]. Only untrusted is in both lists, so it's the only approval policy users can select. A command rule or read denial from either source also applies.

If two sources share no value, such as allowedApprovalsReviewers set to ["auto-review"] in one source and ["user"] in another, Glean Tau applies the most restrictive listed value, user, and reports a warning. Align the lists across sources to avoid this.

A restriction in any source applies to every device that receives it, so you can tighten limits in one source without editing the others. User configuration and remembered approvals can't widen these limits.

Write a policy

Use schemaVersion: 1 for the readable administrator format. For example, an approval-only policy removes Full access while allowing users to choose between the other two approval modes. It permits approved work without a sandbox, so it's an approval policy rather than a required file or network boundary. For the complete example, see Configure approval and sandbox requirements.

The administrator format has five sections:

Field	Purpose
schemaVersion	Selects version 1 of the readable format
enrollment	Requires protected device policy after the device accepts enrollment
permissions	Limits network destinations through a managed proxy
features	Allows or denies features
settings	Sets core.authority.requirements and other app preferences by key

The older settingsSchemaVersion: 1 format remains supported. Don't mix both version fields in one document. See Glean Tau configuration reference.

Identify settings that stay under user control

Some preferences stay under user control. These include accessibility preferences, keyboard shortcuts, Terminal font size, and Explorer word wrap. Policy validation rejects administrator values for user-only settings.

Connected accounts, credentials, individual local Model Context Protocol (MCP) server records, and storage actions aren't ordinary managed preferences. A feature switch doesn't configure these records or grant access to them.

Handle invalid configuration

Validate policy before deployment. On a device that isn't enrolled and has no other managed policy, Glean Tau ignores a malformed, unsupported, or unprotected policy file and runs without its restrictions. It doesn't warn you when this happens. After the device accepts enrollment, or while another source delivers managed policy, the same problem blocks agent work. An invalid security restriction from an active policy source also blocks agent work.

An ordinary invalid preference can be excluded from value selection. That behavior doesn't make the entire source healthy, and it doesn't apply to mandatory security restrictions. Don't rely on unknown keys being enforced across different app versions.

If work stops, correct the delivered source and verify recovery. See Troubleshoot managed settings.

Require policy on a device

Set enrollment to true in a protected device source when agent work must require managed policy. Include features and a core.authority.requirements value under settings in the same document. While a device is enrolled, agent work stays blocked until both are present. Deliver the document before users start agent work.

Only a configuration profile, the protected managed settings file, or verified Windows machine registry policy can deliver enrollment.

Once Glean Tau accepts enrollment, deleting the source, signing out, switching accounts, or restarting doesn't remove the device's policy requirement. A missing or unreadable required source blocks work. Server-managed settings can't create or clear protected device enrollment.

Enrollment protects the agent workflow. It doesn't replace operating-system controls against a person who can replace the app or tamper with its local state. Use standard-user accounts and your endpoint management controls for that boundary.

Update and remove policy

Glean Tau checks for device policy changes while it runs. Server-managed settings refresh on their own schedule and have separate outage behavior. See Understand refresh and outage behavior.

A restriction can stop new work, invalidate a pending approval, or make a feature unavailable. An active task might stop before completion after a policy change. A policy update can't undo an external change that already occurred.

Remove managed policy

Remove ordinary preferences by omitting their keys from the source. Required enrollment and retained device network restrictions need explicit removal.

Use the following rules when removing settings:

Change	Result
Omit an ordinary preference	Removes that source's override
Use an empty allowlist	Allows nothing in that list
Deliver an empty settings document	Supplies no new settings, but doesn't clear retained device restrictions
Remove an enrolled source	Blocks work until required policy is restored or enrollment is cleared correctly
Sign out	Clears account policy, while device policy remains

For an enrolled device, follow this order:

1. Inventory all device sources that require enrollment or retain network restrictions. Keep a backup of their current valid policy.
2. Deliver a valid policy with enrollment: false through each source that enrolled the device. Keep its other required fields valid during this step.
3. If a source has a retained network restriction, explicitly clear that source's core.network.proxy value with null. Don't leave permissions.network in the same document, because it defines the same setting.
4. Confirm that the app accepted each removal on the target device. A successful MDM assignment alone is insufficient.
5. Remove the remaining source overrides or profile assignments, then restart and verify the final behavior.

The following document illustrates an explicit clear for a protected source. It removes security controls from that source, so use it only as part of an approved removal:

Explicit policy removal

{
  "schemaVersion": 1,
  "enrollment": false,
  "settings": {
    "core.network.proxy": null
  }
}

Another source can still require enrollment or restrict the network. An empty file, an empty object, null in an unrelated field, sign-out, or source deletion isn't equivalent to this procedure.

warning

Don't delete local enrollment state to bypass a block. If the original source is no longer available, use Glean support to plan recovery.

Plan upgrades and rollback

Test policy and client upgrades together. An older client might not understand the readable format or newer retained policy state.

Before a downgrade, confirm that the older client supports the current configuration and enrollment state. If it doesn't, complete a supported policy transition while the newer client still runs. Restoring an older installer alone can leave the device blocked.

See also

• Glean Tau security and permissions — how approvals, sandboxing, and operating-system permissions combine
• Configure your access — how users add project folders and exclude sensitive paths within your policy