Claude Code commit guards never fire: $TOOL_INPUT is unset

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#128 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
65/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
github, go
Domaine
cli, security

Piste de recherche

Lisez .claude/settings.json et la référence de Claude Code hooks liée dans l’issue ; l’issue contient des reproductions des guards défaillants et du changement proposé pour l’analyse de stdin. Vérifiez le comportement des guards avec les formes de contournement indiquées, notamment git -C . commit et git commit -am avec un secret non indexé. Le travail est terminé lorsque les guards bloquent les cas indexés décrits et qu’un check CI couvre les cas de contournement de l’issue.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

The two PreToolUse guards on Bash in .claude/settings.json (sensitive files and secrets in a commit) exit 2 correctly, but they can't fire: they read $TOOL_INPUT, which Claude Code doesn't set. The call arrives as JSON on stdin (hooks reference: "For command hooks, input arrives on stdin"), so grep -q 'git commit' never matches and both exit 0. Their messages also go to stdout; Claude Code shows a blocking hook's stderr, so Claude wouldn't see why.

A fix that keeps your checks and messages:

{ "type": "command", "command": "if jq -r \".tool_input.command // empty\" | grep -q 'git commit'; then git diff --cached --name-only | grep -E '\\.(env|pem|key|p12)$' && echo '⛔ BLOCKED: Sensitive file in commit' >&2 && exit 2 || exit 0; fi" },
{ "type": "command", "command": "if jq -r \".tool_input.command // empty\" | grep -q 'git commit'; then git diff --cached | grep -iE '(api_key|password|secret|token|nyk_v0)' && echo '⛔ BLOCKED: Possible secret in commit' >&2 && exit 2 || exit 0; fi" }

Tested with the JSON Claude Code sends, in a scratch repo with a staged prod.env and a staged api_key = "..." line: today git commit -m wip exits 0 from both guards. With the fix both exit 2, and git status still passes.

With the fix in place, I also ran it against a few spellings agents produce for the same action. Verified: each of these exits 0, so the commit goes ahead: git -C . commit -m wip, and git commit -am wip when the secret is in an unstaged change to a tracked file (the scan reads only what is already staged, and -a stages the rest at commit time).

Would a check like this be useful in CI, one that runs your guards against bypass spellings and fails the build when one gets through?

Found this while testing Claude Code hooks for Paveo, which I build (open source). Happy to open a PR with the fix.

Langage dominant
Go
Étoiles
76
Forks
3
Merge moyen
14 j 15 h
PR mergées (30 j)
3

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de nylas/cli

Toutes les issues de nylas/cli

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.