Granular, Subcommand-Level Permissions for Tool Usage

[joshross4]

The Core Idea

First, a big thank you to the team for the security-first design of the Gemini CLI. The interactive prompt for tool execution is a fantastic safety feature.

Based on prompts the "allow always" option is scoped to the command, like mkdir.

This works well for simple commands. However, for powerful, multi-purpose tools like git, docker, or kubectl, the Yes, allow always "git ..." option is still too permissive. It would treat a safe, read-only command like git status the same as a potentially destructive one like git push --force.

My proposal is to introduce a more granular permission level: allowing users to persistently approve specific subcommands (e.g., git status) while ensuring that other, unapproved subcommands from the same tool (e.g., git push) still require a prompt.

The Problem

For complex tools, the current model creates a security vs. convenience dilemma. When Gemini wants to run git status, the prompt looks like this:

? Shell git status (Checking the status of the repository...)

git status

Allow execution?
 ● Yes, allow once
 ○ Yes, allow always "git ..."
 ○ No (esc)

Choosing Yes, allow always "git ..." is a security risk because it would also implicitly approve git reset --hard or other dangerous commands. To stay safe, the user must repeatedly select "allow once" for very common and harmless commands, which leads to prompt fatigue.

Proposed Solution

I propose enhancing the prompt to include a subcommand-specific option, supported by a persistent configuration file and management commands.

1. An Enhanced Interactive Prompt

Let's evolve the prompt to include a more granular "always allow" choice.

Proposed New Prompt (for a git status command):

? Shell git status (Checking the status of the repository...)

git status

Allow execution?
 ● Yes, allow once
 ○ Yes, allow always "git status"
 ○ Yes, allow always "git ..." (all subcommands)
 ○ No (esc)

• Yes, allow always "git status" (New!): This is the core of the idea. It would add only the status subcommand to an allowlist for the git tool. A future git status call would run without a prompt, but a git push call would still trigger one.
• Yes, allow always "git ...": This would retain the current behavior, granting blanket permission for the entire git tool for users who want that convenience.

2. Persistent Permissions via Configuration File

This functionality would be backed by a human-readable config file (~/.gemini/permissions.yaml or similar) where these granular permissions are stored.

Example permissions.yaml:

# Gemini CLI Tool Permissions
# Use '*' in allowed_subcommands to grant full access.
tool_permissions:
  git:
    description: "Permissions for Git version control"
    allowed_subcommands:
      - status
      - diff
      - log

  docker:
    description: "Permissions for Docker container management"
    allowed_subcommands:
      - ps
      - images

  npm:
    description: "Permissions for Node Package Manager"
    allowed_subcommands:
      - "*" # User selected 'allow always "npm ..."'

This makes the system transparent and allows power users to manage permissions by directly editing the file.

3. Dedicated Permission Management Commands

To complete the feature, users should be able to manage these permissions without having to wait for a prompt:

• gemini tool permissions list: Displays the allowlist in a clean format.
• gemini tool permissions add '<tool> <subcommand>': Proactively adds a permission (e.g., gemini tool permissions add 'git log').
• gemini tool permissions remove '<tool> <subcommand>': Revokes a specific permission.

Benefits

• Greatly Improved Security: Users can create a precise allowlist of safe commands without exposing their system to risky operations.
• Reduced User Friction: Eliminates repetitive prompts for trusted, common commands.
• Enhanced Trust and Usability: This would make the CLI feel much smarter and more respectful of user intent, solidifying its role as a helpful and safe assistant.

[ryanjsalva]

It's a good idea. I have to admit that the cognitive load between 3 and 4 options feels significant, but I wonder if we could keep the permissions.yaml idea without necessarily needing to expose a fourth option in the terminal 🤔

[keithballinger]

We've been looking at using https://github.com/vorpaljs/bash-parser to help with this