Hi everyone,

I ran into this exact same frustration while trying to build secure, autonomous agents on top of the CLI. The fact that
workspace-level policies are currently ignored makes it incredibly difficult to enforce per-project security boundaries.

To unblock myself, I ended up building a Python orchestrator
(gemini-cli-headless) that bypasses this bug entirely. If any of you are
trying to enforce policies programmatically or via scripts, my approach might save you some headaches.

Here is what I found while digging into the policy engine, and how I worked around the current limitations:

1. Bypassing Workspace Discovery (The Tier 5 Injection)

Since the engine is currently ignoring local .gemini/policies/*.toml files (which operate at "Tier 3"), I found that the
only way to guarantee a policy is strictly enforced is to inject it at the highest administrative level. My library
dynamically generates a temporary TOML file at runtime and passes it directly to the CLI using the --admin-policy flag (Tier
5). This forces the engine to respect the rules regardless of what is (or isn't) discovered in the workspace directory.
🔗 Read more on how the Tier System hierarchy works under the
hood.

2. The Silent Priority Cap Bug

If anyone here is trying to force a global policy to override default behavior by setting a massive priority (e.g., priority = 9999), be aware that the CLI's internal Zod schema (toml-loader.ts) strictly caps priorities at 999. If you exceed
this, the policy is silently dropped without throwing an error, and the engine defaults back to YOLO mode. You must keep your
TOML priorities between 0 and 999.

3. Structural Anchoring for Paths

If you are writing policies to restrict tools like read_file to specific directories, be careful with how you write the
regex in argsPattern. Because the engine wraps top-level JSON keys in null bytes (\0) during its internal stringification,
you have to anchor your TOML regexes with \\0 to prevent the model from bypassing path restrictions via JSON injection.
🔗 Read more on Null-Byte Anchoring for path
security.

The Broader Solution

While injecting Tier 5 policies works as a bulletproof workaround for now, this issue perfectly illustrates why programmatic
orchestration shouldn't rely on discovering local .toml files. I recently opened a broader discussion (Discussion
#25659) proposing that the official SDK should natively
accept parameters like allowedPaths and allowedTools in code, abstracting this entire TOML engine away for developers
building apps.

I hope these findings help unblock anyone struggling with local policies right now!

fyi @tqz123 @andreififiita @cagataygurturk @jayBana @AlexanderBartash @Xav-Pe @gregorias @rtuin @lpeabody

Uh oh!

"Workspace/.gemini/policies/*.toml are not taking effect." #18186

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions