[FEATURE] --no-hooks flag (for non-interactive mode)

Resolved 💬 3 comments Opened Feb 22, 2026 by Cyrik Closed Feb 26, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

When using claude -p for scripting, automation, or quick one-off queries, all configured hooks still fire — including plugin hooks. This is problematic because:

  1. Plugin hooks can't be conditionally skipped. Unlike your own hooks, you don't control the plugin script, so you can't add logic to no-op in non-interactive mode. Disabling them currently requires editing the plugin manifest directly (anthropics/claude-plugins-official#333).
  1. Hooks designed for interactive sessions don't make sense in -p mode. Format-on-save, notification hooks, and stop-condition evaluators add overhead and can cause unexpected behavior in a simple input → output pipeline.
  1. There's no per-run workaround. There's no --profile system, no mode-aware matcher in hook config, and no way to point to alternative settings. The only option is maintaining a separate project directory with different .claude/settings.json, which is impractical.

-p mode is explicitly designed for scripting and automation, but it shares the full interactive session machinery with no way to opt out of hooks.

Proposed Solution

A CLI flag that disables hook execution for a given run:

claude --no-hooks -p "explain this function"
git diff | claude --no-hooks -p "review this"

This could also be scoped more narrowly if preferred:

  • --no-hooks — skip all hooks entirely
  • --no-plugin-hooks — skip only plugin-contributed hooks, keep user-defined ones

Alternative Solutions

  • Setting an env var and checking it in hook scripts: Works for your own hooks, but not for plugin hooks where you don't control the script.
  • Setting CLAUDE_CONFIG_DIR to a temp directory: Would skip hooks, but also loses your entire config (model, permissions, MCPs, etc.).
  • Maintaining a separate project directory with different .claude/settings.json: Works in theory, but impractical for quick -p one-liners.
  • Uninstalling/disabling plugins before -p runs: Tedious and error-prone, especially in scripts.

None of these are viable for the common case of "I just want a quick piped answer without plugin hooks firing."

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

I have several plugins installed that contribute hooks useful during interactive development (formatting, stop-condition checks, etc.). When I pipe a git diff into claude -p for a quick review, or use it in a shell script, those plugin hooks still fire — adding latency, producing unexpected side effects, or failing in ways that are hard to debug. Since I don't control the plugin hook scripts, I can't add an env var check or mode detection to skip them. I want a clean input → output pipeline without having to uninstall plugins every time I use -p.

Additional Context

Prior art within Claude Code:

  • disableAllHooks already exists as a setting in managed-settings.json for enterprise use (#10544). The internal mechanism to skip hooks is already there — this request is essentially about exposing it as a CLI flag for per-run control.

Similar features in other tools:

  • Codex CLI offers --profile to switch between different config sets per invocation, allowing different hook/plugin behavior for interactive vs scripted runs.
  • Codex CLI also has --ephemeral for lightweight throwaway runs with minimal side effects.

Technical considerations:

  • Implementation could potentially reuse the existing disableAllHooks code path, just triggered by a CLI flag instead of a settings file entry.
  • A mode-aware hook matcher (e.g., matching on session_type: "print") would be an alternative design, but a simple --no-hooks flag covers the main use case with less complexity.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗