Allow configuring auto-approval for cd+git compound commands

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/30435
2. https://github.com/anthropics/claude-code/issues/31523
3. https://github.com/anthropics/claude-code/issues/30213

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I highly support this request; chained commands are so painful, not only in cd && git case, but many other safe things are hit, like cat - an absolutely legitimate command in my settings, but...

I always have to allow manually such constructions:

 Bash command

   cat -n app/Foo.php && echo "---" && cat -n app/Bar.php
   Show new service files

 Command contains quoted characters in flag names

Agreed, this is a major PITA..

Please fix!

Workaround with a PreToolUse hook: auto-approve cd+git compounds when the git operation is read-only (log, diff, status, branch, show, etc.), while keeping manual approval for destructive operations (push, reset, clean).

npx cc-safe-setup  # includes this hook

Or standalone: cd-git-allow.sh

Returns permissionDecision: allow for safe git operations, passes through for everything else.

I'm a solo developer building a CRM, I can't walk away and come back to a finished task because this prompt blocks every session

This is exactly what the cd-git-allow hook was built for:

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$COMMAND" ] && exit 0
if ! echo "$COMMAND" | grep -qE '^\s*cd\s+.*&&\s*git\s'; then
    exit 0
fi
GIT_CMD=$(echo "$COMMAND" | grep -oP '&&\s*git\s+\K\S+')
case "$GIT_CMD" in
    status|log|diff|show|branch|tag|remote|ls-files|rev-parse|describe|blame|shortlog|stash)
        jq -n '{hookSpecificOutput:{hookEventName:"PreToolUse",permissionDecision:"allow",permissionDecisionReason:"cd+git compound auto-approved (read-only git operation)"}}'
        ;;
    add|commit)
        jq -n '{hookSpecificOutput:{hookEventName:"PreToolUse",permissionDecision:"allow",permissionDecisionReason:"cd+git compound auto-approved (staging/commit)"}}'
        ;;
esac
exit 0

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/cd-git-allow.sh" }]
    }]
  }
}

This auto-approves cd /path && git status, cd /path && git log, cd /path && git add && git commit etc., while still requiring manual approval for destructive operations like git push, git reset --hard, git clean.
The hook runs before the "bare repository attack" check, so the compound command safety prompt is bypassed for trusted operations.

why is this still an issue????

it's making me nutty

Use absolute paths and git -C instead of cd + command chains, but this is less ergonomic and requires changing habits.

I've used this approach for weeks, but it's not really any better, because the claude permission system doesn't seem to have a great way to say "allow -C with any git subcommand I generally marked as safe". I've since switched back to letting claude try cd ... & git ...

Either way, this is a real pain for any case where you're asking claude to do any multi-repo work, e.g. do a similar refactor/dep-upgrade/whatever across many repos ("I've cloned N repos into the CWD: update them all in this way!"), or edit one repo while consulting git history in other repos ("this behavior broke in the CWD repo, and it's probably due to some change in this other dependency repo: please investigate!").

---

It seems like it'd be trivial for the claude harness do any or all of:

1. Just check if it looks like there's a bare repo embedded somewhere within the given cd path, and only ask when there is such a bare repo (ideally also checking for the presence of any local hooks within, and perhaps permitting if there are no such hooks).
2. Configurably check git --version and git config --global safe.bareRepository for safe values. Mine is set to explicit alongside a new enough version, so afaict, I'm completely insulated from this attack, thus this claude heuristic is a complete nuisance in my case.
3. Offer a "do you trust this repo at <path>?" prompt when first encountered, and then disabling that heuristic when involving the same cd path. Ideally this would be based on configured git remote(s), so that if I have the same repo checked out in multiple places, in effect, I only really need to approve a given remote, rather than needing to re-approve every separate clone.

With any of those, it should cut down on these annoying permission prompts considerably.