Glean Tau configuration reference

Write an administrator policy for the tasks your users need. Use the readable format on this page for new configurations, then deliver it through a supported policy source. See Choose where to set a managed value.

Choose a policy example

These examples serve different access requirements. Review the complete document before deployment.

Example	Intended use	Platform
Approval-only policy	Exclude Full access while users can still turn off Sandbox Mode	macOS and Windows
Restricted local workspace	Require sandboxing, exclude sensitive paths, and limit network destinations	macOS
Managed app preferences	Enforce appearance, update channel, and external model-provider availability	macOS and Windows

Download the administrator JSON schema for editor validation. Schema validation checks document shape. It doesn't prove that paths, features, or the installed device support the requested policy.

Define the document

Every readable administrator document uses schemaVersion: 1. Add only the sections you intend to manage.

Managed app preferences
{
  "schemaVersion": 1,
  "settings": {
    "desktop.appearance.theme": "system",
    "desktop.updates.channel": "stable",
    "core.modelProviders.enabled": false
  }
}

This policy enforces its values. It doesn't provide optional defaults. Keep credentials and tokens out of configuration files and profiles.

The following fields are optional unless stated otherwise.

Field	Accepted values	Behavior when omitted
`schemaVersion`	`1`, required	Document is invalid
`enrollment`	`true` or `false`. `true` also needs `features` and `core.authority.requirements`	Doesn't change retained enrollment
`permissions`	Object with a `network` section. See Limit network destinations	Adds no managed network restriction
`features`	Object with `allow` and `deny` lists	Adds no feature restriction
`settings`	Object of supported setting keys and values, including `core.authority.requirements`	Adds no approval, sandbox, or preference limit

Configure approval and sandbox requirements

Set approval and sandbox limits in the core.authority.requirements object under settings. Each list names the values users can select. Omit a list to leave that value unrestricted.

Field in `core.authority.requirements`	Accepted values	When omitted
`allowedSandboxModes`	`read-only`, `workspace-write`, `danger-full-access`	All modes allowed
`allowedApprovalPolicies`	`untrusted`, `on-request`, `never`	All policies allowed
`allowedApprovalsReviewers`	`user`, `auto-review`	Both reviewers allowed
`shellEnvironmentPolicy`	Object. See Filter command environment variables	No filtering

allowedSandboxModes sets the widest sandbox modes users can select. read-only is always allowed, so ["workspace-write"] allows both workspace-write and read-only.

Each approval mode in the app corresponds to one value from each list:

Approval mode	`sandboxMode`	`approvalPolicy`	`approvalsReviewer`
Ask for approval	`workspace-write`	`untrusted`	`user`
Approve for me	`workspace-write`	`on-request`	`auto-review`
Full access	`danger-full-access`	`never`	`user`

danger-full-access also controls whether users can turn off Sandbox Mode in Ask for approval or Approve for me. Leave it out of allowedSandboxModes to require sandboxing.

The three values are independent. Full access is available only when your policy allows all three of its values. For the other modes, a restriction on one value changes only that value. For example, allowedApprovalsReviewers: ["user"] keeps Approve for me's approval policy and sandbox, but a person answers its review requests.

If a user's selection isn't allowed, Glean Tau replaces only the disallowed value and keeps the user's saved choice:

A disallowed sandbox mode becomes the widest allowed mode that's no wider than the selection. Turning off Sandbox Mode becomes workspace-write when you allow it, otherwise read-only.
A disallowed approval policy becomes the first value in your list that's no less strict than the selection. If every allowed value is less strict, the strictest one applies. List values in the order you prefer as the fallback.
A disallowed reviewer becomes the first reviewer in your list.
When Full access isn't allowed, the user's saved approval, reviewer, and sandbox values apply instead, each limited in turn.

Users see one notice for each replaced value beside the composer access picker and in Settings → Agent access, such as "Your organization turned the sandbox on." A combination that matches no named mode gets a descriptive label instead of a mode name.

allowedApprovalPolicies doesn't decide who answers a request. ["untrusted"] alone makes each action ask for approval, but automatic review can still answer. Add allowedApprovalsReviewers: ["user"] when a person must answer.

If a user had saved never with Sandbox Mode off, outside Full access, and your policy requires a sandbox, Glean Tau refuses to run the chat. The user resolves it by choosing an approval mode in the composer.

Each list must contain at least one supported value, with no duplicates. An empty or malformed list makes the policy invalid, and Glean Tau blocks agent work until you correct it. Use auto-review for the reviewer. Glean Tau doesn't accept the spelling auto_review. Check the document before deployment.

Glean Tau ignores an unknown field at the top level of core.authority.requirements with a warning, so a document written for a newer client still applies on older clients. A field that looks like a misspelling of a known field, such as allowed_sandbox_modes or allowedApprovalReviewers, makes the policy invalid instead. An unknown field inside a known section also makes it invalid.

Use this complete approval-only example to exclude Full access while preserving the other modes:

{
  "schemaVersion": 1,
  "settings": {
    "core.authority.requirements": {
      "allowedApprovalPolicies": ["untrusted", "on-request"]
    }
  }
}

Because the example doesn't restrict allowedSandboxModes, users can still turn off Sandbox Mode. To also require sandboxing, add "allowedSandboxModes": ["read-only", "workspace-write"].

Start from a baseline

This example requires sandboxing, removes Full access, lets users choose a person or automatic review, excludes common credential directories, and sends git push to review:

Baseline requirements
{
  "schemaVersion": 1,
  "settings": {
    "core.authority.requirements": {
      "allowedSandboxModes": ["read-only", "workspace-write"],
      "allowedApprovalPolicies": ["untrusted", "on-request"],
      "allowedApprovalsReviewers": ["user", "auto-review"],
      "permissions": {
        "filesystem": {
          "denyRead": ["~/.ssh", "~/.aws", "~/.kube", "~/.config/gcloud"]
        }
      },
      "rules": {
        "prefixRules": [{ "pattern": ["git", "push"], "decision": "prompt" }]
      }
    }
  }
}

In Approve for me, automatic review can approve a prompt command. Tighten this baseline for groups that need it. For example, deny Browser Use and Computer Use where signed-in browser sessions are out of scope, and limit network access where command traffic must be controlled.

Configure automatic review

To require Approve for me, set allowedApprovalPolicies to ["on-request"] and allowedApprovalsReviewers to ["auto-review"]. Glean Tau can still ask a user when automatic review can't decide safely.

Use sentinelExtraPolicy in core.authority.requirements to add organization instructions to each automatic review. It accepts a string of up to 4,000 characters. These instructions guide the reviewer. They don't replace enforceable file, network, command, mode, and feature restrictions.

The optional settings key desktop.authority.reviewModel takes an object with provider and id strings. Use a model reference supported by your deployment. Confirm the reference with Glean before changing it. This setting selects the review model, not the model that answers the chat.

Control commands

Use rules.prefixRules in core.authority.requirements to allow, prompt for, or forbid commands that start with a given sequence of arguments.

Field in each rule	Meaning
`pattern`	Command arguments to match from the start, such as `["git", "push"]`
`decision`	`allow`, `prompt`, or `forbidden`
`justification`	Optional explanation for the decision

Each item in pattern is a string, { "token": "…" }, or { "anyOf": ["…", "…"] } to match one of several arguments. When several rules match, the strictest decision applies: forbidden, then prompt, then allow.

This example forbids git push and requires review for commands that start a shell:

{
  "schemaVersion": 1,
  "settings": {
    "core.authority.requirements": {
      "rules": {
        "prefixRules": [
          {
            "pattern": ["git", "push"],
            "decision": "forbidden",
            "justification": "Don't push from managed workstations."
          },
          {
            "pattern": [{ "anyOf": ["bash", "sh", "zsh"] }],
            "decision": "prompt"
          }
        ]
      }
    }
  }
}

Within sandboxed modes, an admin allow rule lets a matching command run outside the sandbox, unless denyRead is set. Add allow rules only for commands you trust.

Command rules from every admin source apply together.

Limit filesystem access

Use permissions.filesystem.denyRead in core.authority.requirements to list paths that sandboxed commands and file tools can't read.

Use absolute paths or paths that start with ~/. The app resolves ~ for the user running Glean Tau. Paths can't use .. to navigate to a parent directory. Glob patterns such as *.env are unsupported. List an exact file or a directory instead.

Read denials from every admin source remain in effect. User configuration and remembered approvals can't remove them.

A denyRead list limits sandbox modes to read-only and workspace-write. Full access becomes unavailable, and turning off Sandbox Mode keeps sandboxing on.

Require a restricted workspace

This complete example requires sandboxing, excludes a credential directory, forbids git push, and permits package downloads through a managed network proxy. It allows a small feature set that supports the managed proxy, including glean, which agent access requires.

Restricted local workspace
{
  "schemaVersion": 1,
  "enrollment": true,
  "permissions": {
    "network": {
      "allow": ["registry.npmjs.org"],
      "ports": [443]
    }
  },
  "features": {
    "allow": ["glean", "terminal"]
  },
  "settings": {
    "core.authority.requirements": {
      "allowedSandboxModes": ["read-only", "workspace-write"],
      "allowedApprovalPolicies": ["untrusted", "on-request"],
      "allowedApprovalsReviewers": ["user", "auto-review"],
      "rules": {
        "prefixRules": [
          {
            "pattern": ["git", "push"],
            "decision": "forbidden",
            "justification": "Don't push from managed workstations."
          }
        ]
      },
      "permissions": {
        "filesystem": {
          "denyRead": ["~/Company/Code/credentials"]
        }
      }
    }
  }
}

Create the intended folders before testing, then test allowed and denied operations. Don't deploy this example unchanged across a fleet.

A feature allowlist retains required app services. It doesn't grant all network traffic for those services through the process allowlist.

Filter command environment variables

Use shellEnvironmentPolicy in core.authority.requirements to limit the environment variables that agent shell commands inherit. This keeps secrets in the user's environment out of agent commands.

Field	Accepted values
`inherit`	`all` (default), `core` for a platform-specific set of core variables, or `none`
`ignoreDefaultExcludes`	Boolean. Defaults to `true`, which skips the built-in exclusions for secret names
`exclude`	Case-insensitive patterns, using `*` and `?`, for variables to remove
`includeOnly`	Case-insensitive patterns, using `*` and `?`, for the only variables to keep

If filtering removes PATH or HOME, Glean Tau restores safe values for them.

Filter secrets from command environments
{
  "schemaVersion": 1,
  "settings": {
    "core.authority.requirements": {
      "shellEnvironmentPolicy": {
        "ignoreDefaultExcludes": false,
        "exclude": ["*_TOKEN", "*_SECRET", "AWS_*"]
      }
    }
  }
}

Limit network destinations

A permissions.network object requires an allow list and a supported managed proxy. All listed destinations use the same ports list. On Windows, Glean Tau doesn't enforce the managed proxy, and the policy doesn't block agent work.

The fields control destination access:

Field	Meaning	Default
`allow`	Allowed hostnames, including supported subdomain patterns such as `*.packages.example.com`	Required. An empty list allows no destinations.
`deny`	Denied domains	Empty list
`ports`	Integer ports from 1 to 65,535	`[443]`
`allowPrivate`	Permit nonpublic network addresses	`false`
`allowLocal`	Permit addresses on the local machine	`false`
`allowMetadata`	Permit cloud instance metadata addresses	`false`

When policy requires the managed proxy, Full access is unavailable and sandboxed commands can't make direct network connections.

Some features can't route all their traffic through the managed proxy. On macOS, a policy that requires the proxy must also deny them in features. Otherwise, Glean Tau reports the policy as unsupported and blocks agent work. Deny these feature IDs, or use a features.allow list that leaves them out:

browser, browser-use, and computer-use
activity-journal
git, review, current-pull-request, and gda-managed-worktrees
relay and cloud-agents
external-agent-data-import

Glean Tau doesn't remove these features for you, so test the complete policy on a pilot device before deployment. See Control features.

Address restrictions still apply to an allowed hostname. For example, an internal hostname that resolves to a private address also needs an appropriate private-address allowance. Keep local and metadata access restricted unless the workload needs them.

A domain denial wins over an allowance. Domain rules don't inspect URL paths, repository ownership, HTTP methods, or payloads. This isn't a network policy for every desktop component or other application.

The readable fields don't configure every proxy routing or certificate option. Work with Glean for deployments that need those settings. Don't define both permissions.network and the underlying core.network.proxy setting in the same document.

To turn off network access for sandboxed commands without a proxy, set networkAccess to false in core.authority.requirements. This doesn't restrict commands that run outside the sandbox. Windows doesn't support this setting.

Control features

Use features.allow to permit a selected set, or features.deny to exclude named features. Both lists take feature IDs, not the display names shown in the app.

The following table maps common features to their IDs. For what each feature does, see Extensions.

Feature	ID
Glean	`glean`
Activity Journal	`activity-journal`
Artifacts	`artifacts`
Automations	`automation`
Browser	`browser`
Browser Use	`browser-use`
Cloud Agents	`cloud-agents`
Computer Use	`computer-use`
Dictation	`dictate-anywhere`
External Agent Data Import	`external-agent-data-import`
Generative UI	`generative-ui`
Git	`git`
Goals	`goal`
Local MCP	`glean.local-mcp`
Managed worktrees	`gda-managed-worktrees`
Meeting Notes	`scribe`
Memory	`memory`
Pull requests	`current-pull-request`
Remote Access	`relay`
Review	`review`
Shots	`shots`
Skills	`skill-registry`
Subagents	`subagent`
Terminal	`terminal`
Workbench Control	`workbench-control`

Don't list Glean Tau's safety and containment services. They stay active under any feature policy. The administrator JSON schema doesn't check feature IDs. A misspelled ID in allow leaves that feature unavailable, so check each ID before deployment.

This example denies Computer Use and Browser Use while leaving other feature availability unchanged:

{
  "schemaVersion": 1,
  "features": {
    "deny": ["computer-use", "browser-use"]
  }
}

A present allow list changes feature policy to deny features outside the list. Include glean in every allow list. Without it, agent access is off, and only sign-in and Glean Web remain available. An empty allow list has the same effect. If allow is absent, other features remain eligible. A denial wins even if the same feature appears in allow.

A managed network proxy requires compatible features. On macOS, where Glean Tau enforces the proxy, the following features can't route their traffic through it: Activity Journal, Browser, Browser Use, Cloud Agents, Computer Use, External Agent Data Import, Git and its Review and Pull requests views, managed worktrees, and Remote Access. If policy requires the proxy and allows any of these, Glean Tau blocks agent access. Deny each one, or leave it out of your allow list. Terminal and Workbench Control work with the proxy. Test the selected feature set before deployment.

Use other managed settings

Use settings for supported preferences that don't have readable fields. The following are examples, not an exhaustive catalog.

Key	Value	Purpose
`core.authority.requirements`	Object. See Configure approval and sandbox requirements	Limit approval modes, sandboxing, commands, and file reads
`desktop.appearance.theme`	`system`, `light`, `dark`	Enforce the app theme
`desktop.updates.channel`	`stable` in the managed app preferences example	Select the supported update channel
`desktop.updates.autoDownload`	Boolean. Defaults to `true`	Enforce whether updates download automatically
`desktop.startup.launchAtLogin`	Boolean. Defaults to `false`	Enforce whether Glean Tau opens when the user signs in to the device
`desktop.chat.defaultModel`	Object with `provider` and `id`	Set the starting model for new chats
`desktop.chat.defaultThinkingLevel`	`off`, `low`, `medium`, `high`, `xhigh`, `max`	Set the starting thinking level for new chats
`desktop.chat.newChatModelBehavior`	`useDefault` or `rememberLast`	Start new chats with the default model or the last model used
`desktop.notifications.permissionRequests`	Boolean	Enforce desktop notifications for approval requests
`core.modelProviders.enabled`	Boolean	Permit or prevent external model-provider configuration
`core.telemetry.enabled`	Boolean	Control application telemetry
`core.telemetry.fullExport`	Boolean	Control full task-content export in telemetry
`desktop.authority.reviewModel`	Object with `provider` and `id`	Select the automatic review model
`core.authority.fullAccessAllowed`	`false`	Remove Full access without changing other requirements
`ext.<extensionId>.enabled`	Boolean for a supported optional extension	Enforce its on or off state
`ext.glean.tauEnabled`	`false`	Turn off Glean Tau agent access while retaining sign-in and Glean Web
`ext.browser.cookieImportEnabled`	Boolean. Defaults to `true`	Set to `false` to stop cookie import. The Browser panel stays available
`ext.browser.agentVisibleControlEnabled`	Boolean	Enforce whether agents can control the visible Browser panel
`ext.browser.agentHeadlessControlEnabled`	Boolean	Enforce whether agents and automations can use headless Browser tools

A setting can't create access to a feature the organization doesn't have. A preference that turns a feature on can't override a feature denial.

This example sets the starting model for new chats and turns off Computer Use, Browser Use, Browser, and Terminal. Use a model ID that's available to your organization:

Default model and extension preferences
{
  "schemaVersion": 1,
  "settings": {
    "desktop.chat.defaultModel": { "provider": "glean", "id": "<model-id>" },
    "desktop.chat.newChatModelBehavior": "useDefault",
    "ext.computer-use.enabled": false,
    "ext.browser-use.enabled": false,
    "ext.browser.enabled": false,
    "ext.terminal.enabled": false
  }
}

The default model only selects where new chats start. Users can still choose any available model in a chat. To limit the models users can choose, use model exclusion.

An ext.<extensionId>.enabled preference keeps an extension on or off, but doesn't remove it from feature policy. To make sure a feature can't run, deny it in features. See Control features.

Keep existing configurations

Existing documents with settingsSchemaVersion: 1 and dotted keys in settings remain supported. New readable documents use schemaVersion: 1.

Keep one format per document. Don't define a readable section and its equivalent underlying setting together. For example, permissions.network conflicts with settings["core.network.proxy"], and features conflicts with settings["desktop.extensions.policy"].

Earlier readable documents that set approval, allowedModes, sandbox, rememberApprovals, allowExpansion, or filesystem under permissions are no longer valid. Move approval and sandbox limits to core.authority.requirements, and move read denials to its permissions.filesystem.denyRead list.

Before migration, compare the effective restrictions and test removal and recovery. Changing the file format doesn't clear enrollment or retained device network requirements.

Choose a policy example​

Define the document​

Configure approval and sandbox requirements​

Start from a baseline​

Configure automatic review​

Control commands​

Limit filesystem access​

Require a restricted workspace​

Filter command environment variables​

Limit network destinations​

Control features​

Use other managed settings​

Keep existing configurations​

See also​