Security Risk: Aider silently bypasses pre-commit hooks by default (--no-verify)

[QiuYucheng2003]

Issue

Description:
Aider currently bypasses all local pre-commit hooks (such as SAST scanners, secret leakage detectors, and code formatters) when automatically committing code. This behavior is silent and defaults to bypassing, which poses a security risk for repositories relying on pre-commit checks.

Root Cause Analysis:
Upon reviewing the source code, the issue stems from the default configuration in aider/args.py:
group.add_argument(
"--git-commit-verify",
action=argparse.BooleanOptionalAction,
default=False, # <--- Defaults to bypassing hooks
help="Enable/disable git pre-commit hooks with --no-verify (default: False)",
)

This False value is passed to GitRepo during initialization. Consequently, in aider/repo.py (within GitRepo.commit), the --no-verify flag is unconditionally appended to the underlying git command:
if not self.git_commit_verify:
cmd.append("--no-verify")

Security Impact:
If the LLM generates flawed or malicious code (e.g., via prompt injection from a parsed GitHub Issue or URL) or accidentally includes hardcoded API keys, Aider will bypass the repository's preset security defenses. The harmful code is then pushed directly into the git history without warning.

Proposed Solution:
Change the default value of --git-commit-verify to True in aider/args.py. Bypassing security hooks should be an explicit user opt-in, rather than the default behavior.

Version and model info

Aider version: Latest main branch (Identified via static source code analysis)
Model: N/A (Static Code Analysis)
Git repo: N/A
Repo-map: N/A

[Sarthak816]

I diagnosed the root cause, trying to fix it asap

[Sarthak816]

Done

[chrislazar25]

I'll take a look at this issue and work on a fix.

[rehan243]

Oh yeah, this is a legit concern. Bypassing pre-commit hooks by default feels kinda risky, especially for repos leaning on SAST tools or secret scanners. The --no-verify flag in GitRepo.commit being tied to git_commit_verify=False by default is def the culprit here.

We ran into something similar with a CI/CD pipeline where skipping hooks was the default, and it let some API keys into prod. Not fun. Agree 100% that the safer move is flipping git_commit_verify to True as the default. Makes bypassing an explicit choice, which feels more aligned with secure-by-default principles.

Also, maybe log a warning if someone does use --no-verify, like just to make them aware they're skipping stuff? Turns out, a lot of folks don't even know what it does.

[shleder]

Regarding the silent --no-verify bypass of git hooks in automated agent commits:

This highlights a fundamental limitation of relying on application-level flags for git security. Whether an agent passes --no-verify or subshells directly into git commit, in-process safeguards are easily omitted.

To enforce immutable git guardrails across AI agents (Aider, Codex, Claude Code) without breaking automated workflows, Vetto provides native OS-level git wrapping:

# 1. Install transparent native shims and git hook wrappers:
npx @shledery/vetto hook install

# Or wrap Aider directly in a sandboxed session:
vetto --agent aider -- aider

How Vetto handles Git and pre-commit security:

• Git Hook Invariance: Enforces mandatory repository pre-commit checks through an external git core hook barrier that cannot be disabled via --no-verify in child shells.
• Fail-Closed Secret Masking: Masks ~/.ssh/id_rsa, .env, and cloud credentials to /dev/null at the kernel VFS layer before Aider spawns, preventing secrets from being staged or committed into history in the first place.
• Zero-Latency Native Execution: Operates via Linux Landlock / macOS Seatbelt with no Docker or VM overhead.