Skip to content

Feature Request: Implement a Hooks System for Custom Automation and Workflow Integration #2779

@coygeek

Description

@coygeek

Title: Feature Request: Implement a Hooks System for Custom Automation and Workflow Integration

Labels: feature-request, enhancement, automation, integrations

Is your feature request related to a problem? Please describe.

I'm a frequent user of the Gemini CLI and find it incredibly powerful for day-to-day development tasks. However, as I integrate it more deeply into my team's workflow, I'm finding a ceiling where I need more deterministic control over the agent's behavior. Currently, I have to rely on complex prompts to enforce our team's standards (e.g., "remember to run the linter after you edit a file"), which is unreliable and varies with the model's interpretation.

Describe the solution you'd like

I'd like to propose the implementation of a "Hooks" system. This feature, recently introduced in a competitor tool (Claude Code), has proven to be a game-changer for agentic CLI tools.

The core concept is to allow users to register custom shell commands or scripts that are automatically executed at specific lifecycle events within the Gemini CLI. This would shift certain responsibilities from probabilistic "prompting" to deterministic, application-level "configuration."

A potential implementation could look like this:

1. Configuration: Hooks could be defined in a project-level (.gemini/settings.json) or user-level (~/.gemini/settings.json) configuration file.

2. Lifecycle Events: The system would expose key events to hook into, such as:

  • PreToolUse: Runs before the agent executes a tool (like Bash or FileEdit). This hook could validate, modify, or even block the tool call.
  • PostToolUse: Runs after a tool successfully executes.
  • Notification: Triggers when the agent requires user attention (e.g., for a permission prompt).
  • Stop: Triggers when the agent has finished its task and is about to exit.

3. Data Flow: A hook script would receive a JSON payload on stdin containing context about the event (e.g., tool_name, tool_input, session_id). The script could then return its own JSON on stdout or use exit codes to signal success, failure, or a decision to block the agent's action.

Describe alternatives you've considered

The current alternative is to add complex, repetitive instructions to my prompts or to a GEMINI.md file. For example: "After you edit any .ts file, you must run npm run format." This is fragile because:

  • The model can forget or ignore the instruction.
  • It consumes valuable context window space.
  • It doesn't scale well across a team or for complex rule-sets.

Another alternative is to write wrapper scripts around the Gemini CLI, but this is clunky and can't intercept internal events like individual tool usage.

Use Cases & Benefits

A hooks system would unlock powerful workflows and make the Gemini CLI much more suitable for enterprise and team environments:

  • Automated Code Formatting: Automatically run prettier, black, or gofmt after any FileEdit hook to ensure consistent code style without prompting.

    // Example PostToolUse Hook
    "matcher": "FileEdit",
    "command": "./scripts/run-formatter.sh" 
  • Custom Guardrails & Linting: Block or provide feedback on undesirable commands. For example, a PreToolUse hook could detect grep and instruct the model to use the more performant ripgrep instead, returning an error message that feeds directly back into the model's context.

  • Enhanced Security: A PreToolUse hook could prevent the agent from editing sensitive files (e.g., terraform.tfvars, production.yml) or running destructive commands (rm -rf). This is a critical feature for enterprise adoption.

  • Compliance & Auditing: A PreToolUse hook on the Bash tool could log every single command the agent executes to a secure audit file.

  • Custom Notifications: A Notification hook could post a message to a Slack channel when the agent needs human input on a long-running task.

  • Automated Feedback Loops: A Stop hook could be configured to automatically run the project's test suite one last time and, if tests fail, prevent the agent from stopping and instruct it to fix the new failures.

This feature would be a massive leap forward, empowering developers to build truly robust, reliable, and customized workflows on top of the Gemini CLI. Thank you for considering this request

Metadata

Metadata

Labels

area/coreIssues related to User Interface, OS Support, Core Functionality🔒 maintainer only⛔ Do not contribute. Internal roadmap item.
No fields configured for Feature.

Projects

Status

Closed

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions