Fix "Cannot enable privileged approval modes in an untrusted folder"

Trying to switch Gemini CLI into YOLO or auto-edit mode and getting "Cannot enable privileged approval modes in an untrusted folder"? The CLI is refusing because the directory you are working in has not been marked as trusted. This is a deliberate safety check, not a bug.

The Error

Error: Cannot enable privileged approval modes in an untrusted folder.

It appears when you try to change approval mode — via --yolo, the /approval-mode control, or an auto-accept toggle — in a workspace Gemini CLI considers untrusted.

Why This Happens

Gemini CLI defines four approval modes:

When you set an approval mode, the CLI checks whether the workspace is trusted. If it is not trusted and the requested mode is anything other than default or plan, it throws this error.

The reasoning is sound. Auto-edit and YOLO let the model modify files and run commands without asking each time. Granting that inside a repository you have just cloned and not read is exactly how a malicious project configuration turns into code execution on your machine. Plan mode remains available precisely because it inspects without acting.

How trust is actually resolved

The resolution order matters, and explains most of the confusing cases:

1. If your IDE reports a workspace trust state, that wins. Opening the folder in VS Code Restricted Mode marks it untrusted for Gemini CLI too, regardless of what you configured in the CLI.
2. Otherwise, if the folder trust feature is enabled, the CLI uses the recorded decision for that directory — and defaults to untrusted when no explicit decision exists.
3. If the folder trust feature is disabled, every folder counts as trusted.

Point 2 is the one that surprises people: an unfamiliar directory is untrusted by default. You have not done anything wrong; you simply have not yet said the folder is safe.

Fix 1: Trust the Folder

The intended fix is to record an explicit trust decision for the directory you are working in.

Start Gemini CLI in that directory and answer the trust prompt when it appears. If you previously dismissed it, or you are in a directory you have not opened before, no decision has been recorded yet and the folder stays untrusted.

Do this only for directories whose contents you have actually reviewed. The check exists to protect against unfamiliar code, so trusting reflexively defeats it.

Once trusted, switching to auto-edit or YOLO works normally — see Gemini CLI YOLO mode for what that mode actually permits before you enable it.

Fix 2: Check Whether Your IDE Is Overriding the Decision

If you trusted the folder and still get the error, an IDE is the most likely culprit, because IDE-supplied trust takes priority over the CLI's own setting.

In VS Code, look for the Restricted Mode banner at the top of the window. A workspace in Restricted Mode is reported as untrusted, and Gemini CLI honours that. Choose to trust the workspace in the editor, then restart the CLI session so it picks up the new state.

This is worth checking early — it produces the frustrating pattern where the CLI's own trust setting looks correct and the error persists anyway.

Fix 3: Confirm You Trusted the Right Path

Trust is recorded per directory. Two things go wrong:

• You trusted a parent, not the working directory — or the reverse.
• You are running through a symlink, so the path the CLI records differs from the path you think you are in.

Confirm where you actually are before re-trusting:

pwd -P    # resolves symlinks to the real path

Then start the session from that resolved path.

Fix 4: Use Plan Mode Instead

If you are working in a repository you genuinely do not want to trust — reviewing an unfamiliar dependency, auditing a third-party project — the right answer is not to force privileged mode. Use plan mode, which is explicitly permitted in untrusted folders and lets the model read and reason about the code without taking actions.

This is usually the better call for exactly the situation that triggers the error: you are somewhere unfamiliar, which is when unattended execution is least appropriate.

What Not To Do

Do not disable folder trust as a reflex. The security.folderTrust.enabled setting turns the feature off, which makes every directory count as trusted and requires a restart to take effect. That removes the safeguard globally rather than granting it for the one project you care about — so a repository you clone next month gets unattended execution with no prompt at all.

If you do decide the feature does not fit your workflow, make it a deliberate, informed choice rather than a way of dismissing an error message. Trusting individual reviewed directories achieves the same result for your daily work while keeping the protection where it matters.

Verify the Fix

Start a session in the directory and switch to the mode you wanted. Success is the mode changing without an error.

If you are unsure which mode is active, or whether YOLO is available at all, check the CLI's mode indicator — YOLO is reported as unavailable when either it has been explicitly disabled or the folder is untrusted, so an unavailable YOLO with a trusted folder points at a separate configuration setting rather than trust.

For related permission failures that are about file and command access rather than approval mode, see Gemini CLI permission denied errors.

Prevention

• Trust project directories deliberately when you first set them up, rather than discovering the restriction mid-task.
• Keep VS Code workspace trust and CLI trust consistent for the projects you work in daily, so the two do not disagree.
• Default to plan mode in unfamiliar repositories. It is available everywhere and is the appropriate posture for code you have not read.
• Leave security.folderTrust.enabled on. The cost is one prompt per new project; the benefit is that an unreviewed clone cannot run unattended commands.

Summary

1. Untrusted folders permit only default and plan — autoEdit and yolo are blocked by design
2. Untrusted is the default when folder trust is on and no decision has been recorded
3. Trust the specific directory you have reviewed to unblock privileged modes
4. Check your IDE — VS Code Restricted Mode overrides the CLI's own trust value
5. Verify the resolved path with pwd -P if trust does not seem to stick
6. Prefer plan mode in unfamiliar repositories rather than disabling folder trust globally