google-gemini / google-gemini/gemini-cli
Fine-Grained, Pattern-Based Permission System
- Dominant language
- TypeScript
- Stars
- 107k
- Forks
- 14.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 45
Description
### What would you like to be added?
I would like to see an enhancement to the existing tool permission system to support **fine-grained, pattern-based rules** (such as glob patterns or regex) for tool arguments within `settings.json` and the Policy Engine.
Currently, `tools.allowed` and `tools.exclude` in `settings.json` appear to support basic tool names or simple prefix matching for shell commands (e.g., `run_shell_command(git)`). I propose extending `packages/core/src/utils/tool-utils.ts` and the Policy Engine to support wildcard patterns for *any* tool argument.
**Desired Configuration Examples:**
* **Allow editing only test files:**
`Edit(src/tests/**/*.ts)` or `write_file(path: **/tests/*.test.ts)`
* **Allow specific npm scripts:**
`run_shell_command(npm run test:*)`
* **Allow reading only specific documentation:**
`read_file(docs/**)`
### Why is this needed?
* **Security & Trust:** The current "all-or-nothing" or "simple prefix" approach forces users to either block tools entirely or trust them completely. A granular system allows users to define "safe zones" (like a `tests/` directory) where the AI can operate freely, while still requiring confirmation for sensitive files (like `.env` or `src/core/`).
* **Developer Experience:** Developers often run repetitive commands (like `git status`, `git diff`, or specific test runners). Being able to whitelist these specific patterns removes friction (constant confirmation dialogs) without exposing the system to dangerous commands like `rm -rf`.
* **Enterprise Compliance:** Security teams need to enforce policies. They might want to allow `curl` only to internal domains or restrict file writes to specific temporary directories.
### Additional context
I've reviewed the current codebase in `gemini-cli-packed.xml` and found the following relevant areas:
1. **Current Matching Logic:**
In `packages/core/src/utils/tool-utils.ts`, the function `doesToolInvocationMatch` currently checks permissions. It appears to rely on simple string equality or prefix matching:
```typescript
// packages/core/src/utils/tool-utils.ts
if (command === argPattern || command.startsWith(argPattern + ' ')) {
return true;
}
```
This should be updated to support glob matching (e.g., using `minimatch` or `picomatch`).
2. **Policy Engine:**
The `packages/core/src/policy/policy-engine.ts` and `types.ts` already support an `argsPattern` (RegExp). However, this seems primarily accessible via complex TOML configuration files in the `.gemini/policies` directory. Exposing a simplified "Glob" syntax in the user-friendly `settings.json` `tools.allowed` list would make this powerful feature accessible to standard users.
3. **Implementation Location:**
The parsing logic in `packages/core/src/utils/shell-permissions.ts` and `tool-utils.ts` would need to be updated to recognize patterns.
**Example from similar tools (Claude Code):**
Claude Code supports rules like `Bash(git diff:*)` or `Edit(docs/**)`, which provides a great balance between safety and autonomy.
Contributor guide
Assessment
This issue has not been assessed yet.