What happened?
The Gemini CLI's security policy engine is bypassed when a target file is open in the IDE. Explicit [[rule]] definitions with decision = "deny" (even with priority = 999) are ignored for file-editing tools (like replace) if the file is currently active or open in the IDE's editor context.
When the file is closed, the policy correctly returns Tool execution denied by policy. When the file is opened, the tool call proceeds to the execution phase, completely bypassing the policy engine's check.
What did you expect to happen?
The Gemini CLI's security policy engine is bypassed when a target file is open in the IDE. Explicit [[rule]] definitions with decision = "deny" (even with priority = 999) are ignored for file-editing tools (like replace) if the file is currently active or open in the IDE's editor context.
When the file is closed, the policy correctly returns Tool execution denied by policy. When the file is opened, the tool call proceeds to the execution phase, completely bypassing the policy engine's check.
Client information
Client Information
Run gemini to enter the interactive CLI, then run the /about command.
> /about
CLI Version: 0.37.1 Git Commit: 3b2d4f100
Model: Auto (Gemini 3)
Sandbox: no sandbox
OS: linux
Auth Method: Signed in with Google (johndoe@gmail.com)
Tier: Gemini Code Assist in Google One AI Pro
IDE: Client VS Code ```
</details>
### Login information
Google Account via OAuth
### Anything else we need to know?
We reproduced this using a workspace-level policy (.gemini/policies/protect_hooks.toml) with the following rule:
```toml
[[rule]]
toolName = ["write_file", "replace"]
argsPattern = '"file_path":"[^"]*(hooks/|state\.sh|checks\.sh)"'
decision = "deny"
priority = 999
denyMessage = "Security Policy: Modification of hooks is strictly prohibited."
Reproduction Steps:
- Define the policy above to protect a specific directory.
- Attempt to use the replace tool on a file in that directory while it is closed in the IDE → Success (Blocked by policy).
- Open the same file in the IDE so it appears in the activeFile context.
- Attempt the same replace call → Fail (Security Bypass): The tool executes and only fails if there's a matching error (e.g., Expected 1 occurrence), confirming the policy check was skipped.
What happened?
The Gemini CLI's security policy engine is bypassed when a target file is open in the IDE. Explicit [[rule]] definitions with decision = "deny" (even with priority = 999) are ignored for file-editing tools (like replace) if the file is currently active or open in the IDE's editor context.
When the file is closed, the policy correctly returns Tool execution denied by policy. When the file is opened, the tool call proceeds to the execution phase, completely bypassing the policy engine's check.
What did you expect to happen?
The Gemini CLI's security policy engine is bypassed when a target file is open in the IDE. Explicit [[rule]] definitions with decision = "deny" (even with priority = 999) are ignored for file-editing tools (like replace) if the file is currently active or open in the IDE's editor context.
When the file is closed, the policy correctly returns Tool execution denied by policy. When the file is opened, the tool call proceeds to the execution phase, completely bypassing the policy engine's check.
Client information
Client Information
Run
geminito enter the interactive CLI, then run the/aboutcommand.Reproduction Steps: