Agent approval modes

Choose an approval mode to control how Glean Tau reviews actions on your computer and in connected apps. Set the mode in the composer, and use Settings → Agent access to set your global preference.

Approval modes

Approval modes determine who reviews work that needs permission. They don't replace your organization's restrictions or the operating system's permissions.

The following table compares the three modes.

Mode	Review behavior	When to use it
Ask for approval	Sends actions that require review to you	Tasks where you want direct oversight
Approve for me	Uses automatic review when needed and asks you when it can't approve the action	Everyday work with a defined goal and scope
Full access	Skips ordinary action review and turns off the user sandbox setting	Workflows where you accept broad local access and your organization permits it

An action already permitted by an applicable rule or scoped approval can run without another prompt. A mode isn't a promise that every file read, app operation, or background request will show a confirmation.

Unattended automations can't depend on you answering a prompt. Test their access mode and policy with a manual run before you schedule them. See Automations.

Ask for approval

Use Ask for approval when you want to review actions that need permission yourself. Read the requested command, file access, destination, or external effect before selecting Allow.

With Sandbox Mode on, file writes inside your project's writable folders run without a prompt, because the sandbox bounds them. Writes elsewhere, and commands that aren't already trusted, still ask you. Turning off Sandbox Mode doesn't reduce prompts in this mode. Glean Tau asks before every file write.

This mode doesn't make a command harmless after you approve it. Check your Sandbox Mode and the access shown on the approval card, especially for commands from an unfamiliar repository. See Choose a sandbox mode.

Approve for me

Approve for me is the default. Glean Tau first applies its fixed rules and your organization's restrictions. Routine work permitted by those rules can proceed. Work that needs closer review can go to an automatic reviewer.

The reviewer evaluates the proposed action in the context of your request. Shell commands, terminal input, browser and computer interactions, and connected-service operations can need this review. The result can be permission to proceed, a request for your decision, or a denial.

Automatic review follows these limits:

It can't override an admin denial or a required sandbox boundary
Some actions require a human decision
If review is unavailable, times out, or can't validate its result, an interactive task can ask you instead
If no user decision is available, the action doesn't proceed
A cancelled action or one whose permissions changed can't use a late review result to run

Automatic review can make mistakes. Keep the task specific and review consequential changes before you publish, send, or deploy them.

Full access

Full access permits broad local work without ordinary action review or the dangerous-command checks. You confirm the change with Enable full access. For a project, the selection applies to chats in that workspace until you change it. When you leave Full access, your previous approval mode and Sandbox Mode setting apply again.

Full access can use files, credentials, and the network available to your account. A selected project folder doesn't limit all file access, and a Git worktree isn't a sandbox.

Your organization's restrictions and operating-system permissions still apply. If an admin excludes this mode, you can't enable it. If a managed execution environment supplies its own boundary, that environment remains in control.

Before using Full access, check whether the task needs broad access to files, credentials, and the network. Use Approve for me or Ask for approval when you need review. Don't switch to Full access merely to clear an unexplained policy error.

Respond to approval requests

An approval card describes the proposed operation and the access it needs. Review the scope before you choose an option. The available options depend on the action, its risk, and your organization's policy.

A card waits until you answer. It closes without allowing the action if you stop the agent, the action is cancelled, or the agent's turn ends.

Choice	Scope
Deny	Stops the requested action
Allow once	Allows the single requested action
Allow for this turn	Allows the stated temporary access for the current agent turn
Allow for session	Remembers the stated access for the active chat session
Always allow	Remembers eligible access for the workspace until you revoke it

An approval covers the stated action and resource. It doesn't grant all actions by that tool. Permission to contact one host doesn't permit every destination, and a file approval doesn't automatically permit its parent directory.

Some high-risk actions can't be remembered, such as running JavaScript on a page. A write to a protected location inside your project, such as Git hooks, offers only Allow once and Deny. A remembered approval can't exceed your organization's restrictions. An action your admin denies doesn't become a request you can approve.

For shell commands, the scope also affects the sandbox. Allow for session keeps the command in the sandbox. Always allow runs the matching command outside the sandbox in later chats in the project. Choose Always allow only for commands you trust.

An approval is evidence that you permitted an action. It isn't proof that the action completed or that the operating system granted every resource it needed.

Manage remembered approvals

Remembered approvals let a matching action run without asking again. The operation, resource, requesting tool, and selected scope must match. What a remembered approval covers depends on the action:

A file write is remembered for the exact path.
A shell command is remembered by its program and leading arguments.
A Browser panel action is remembered for the site and the kind of action, in any tab.
In Chrome, only navigation to a site can be remembered. Other Browser Use actions ask each time.
A Computer Use action is remembered only for the exact text, keys, or click target.
A local MCP tool action is remembered for that tool, with any arguments. High-risk tool calls are remembered only for the exact same arguments.
Terminal input and changes made through Glean's connected-app tools aren't remembered. They ask each time.
A file write is remembered for the exact path.
A shell command is remembered by its program and leading arguments.
A Browser panel action is remembered for the site and the kind of action, in any tab.
In Chrome, only navigation to a site can be remembered. Other Browser Use actions ask each time.
A Computer Use action is remembered only for the exact text, keys, or click target.

Subagents inherit your Always allow approvals for the project.

Allow for session approvals stay with that chat, including after you restart Glean Tau, until you revoke them or delete the chat. Always allow approvals apply to the workspace until you revoke them. Temporary access granted for a turn or for a chat ends when Glean Tau restarts. A later policy change can make an existing approval unusable.

Open Settings → Agent access → Remembered approvals to inspect saved access. Revoke an entry to stop future use of that approval.

Temporary access for this chat lists temporary folders and commands. Remove access when the task no longer needs it. Revocation doesn't undo a file change or external action that has already completed.

Work with untrusted content

A document, web page, repository, email, or tool result can contain instructions that try to redirect the agent. This is a prompt injection attack. Treat content from these sources as information to evaluate, even when it appears in a trusted workflow.

Reduce the effect if the agent acts on a misleading instruction:

Give the agent a specific task and a limited project folder
Exclude credential files and sensitive directories, as described in Configure your access
Review proposed uploads, external messages, destructive changes, and production operations before you approve them
Keep secrets out of prompts

Configure Agent access

Open Settings → Agent access to set approval and sandbox preferences. Your admin can restrict the available choices. Approval modes your admin doesn't allow appear unavailable. Hover one to see why. Settings your admin manages are locked and show a Managed by your organization badge.

Set the global default

Approval mode sets the starting preference for chats that have no more specific choice. It defaults to Approve for me.

A project or working-folder choice takes priority over a chat choice, followed by the global default. Changing the mode in the composer doesn't change the global default. This lets one project use a different mode from your other work.

Admin policy still limits the effective mode. If your saved choice becomes unavailable, Glean Tau uses an allowed fallback and keeps the saved choice. Removing the admin restriction can make that choice apply again.

Your admin can restrict one part of a mode, such as who reviews actions or whether the sandbox can be off. Only that part changes, and a notice beside the access picker explains it, such as "Your organization turned the sandbox on." If the result matches no named mode, the picker shows a descriptive label instead.

Choose a sandbox mode

Sandbox Mode controls whether Glean Tau requests managed execution boundaries for supported local operations. It is separate from the approval mode.

Choice	Effect
On	Requests supported sandbox boundaries for local commands and file writes
Off	Permits approved local work without that requested confinement

Full access sets this control to Off. Glean Tau preserves your saved sandbox preference and restores it when you leave Full access.

Project and chat overrides can take priority over the global preference. Use Reset project override or Reset chat override when shown to remove that override.

The displayed preference doesn't prove that every feature is sandboxed. Platform support and compatibility paths can differ. Read the actual access shown for the operation. Admin policy that requires confinement rejects an operation it can't contain.

Windows supports a required sandbox, but it doesn't support network confinement or enforce a managed proxy. Browser Use and Computer Use also have separate boundaries. See Security and permissions.

Edit your settings file

Select Open settings.json to edit your user settings file in Glean Tau. The file is ~/.glean/ui/settings.json on macOS and %USERPROFILE%\.glean\ui\settings.json on Windows. Use it to set readable access preferences and add explicit project folders.

See Configure your access for complete examples, path rules, and recovery steps. This file is your configuration, and it can't override managed policy.

Approval modes​

Ask for approval​

Approve for me​

Full access​

Respond to approval requests​

Manage remembered approvals​

Work with untrusted content​

Configure Agent access​

Set the global default​

Choose a sandbox mode​

Edit your settings file​

See also​