I was fixing my own app late one evening, and every time I asked for a commit, the same approval screen appeared — even though Bash(git add *) and Bash(git commit *) were both in my allow rules. After about ten presses of "Yes" one evening, my hand stopped.
Looking closer, the prompt wasn't asking about git add or git commit. It was asking about cd.
What I'd like to say first is that this is often not a typo in your allow rules. I could only draw the line after rereading the official permissions page, and I'll write down the path I took.
How to recognize it
If all three of these are true, I'd suspect the same cause.
- Claude emits one chained line such as
cd /path/to/repo && git add ... && git commit .... - The prompt is about
cd, or asks about the whole command. - Choosing "Yes, and don't ask again" doesn't help: the next run shows the same screen.
There is a matching report on GitHub (anthropics/claude-code, issue 28240): on version 2.1.52, on Windows, cd /some/path && git add file && git commit kept asking for cd:* and the approval couldn't be saved for the session. The reporter says earlier versions prompted for git add and git commit instead.
What the official docs say (checked October 13, 2026)
The permissions page has a section on compound commands. Four points stood out.
| Topic | What it says |
|---|---|
| Separators | Split on &&, ||, ;, |, |&, & and newlines; each subcommand is matched against the rules on its own |
| "Don't ask again" | Saves a rule per subcommand that needed approval, not one rule for the whole string (up to 5 rules per compound command) |
cd alone | A cd inside the working directory or an additional directory counts as read-only; cd packages/api && ls runs without a prompt if each part qualifies on its own |
cd with git | If the cd changes into a different directory, it prompts even when each part is read-only, because running git in a new directory can execute that directory's hooks. A cd that resolves to the current working directory is a no-op and doesn't prompt |
So with cd /somewhere-else && git add ..., the combination itself is what gets the prompt, however complete your git rules are. What the issue reported as a bug is now explained in the docs as intended behavior. Whether the behavior at the time of that report matches today's, I haven't verified myself.
One more case: cd combined with a redirect (for example cd app; grep -r pattern . 2>/dev/null) prompts if the redirect target's directory can't be determined. /dev/null is the exception because it doesn't depend on the working directory.
The order I check things in
When a prompt appears, I go through these in order.
- Read which command is being asked about. If it's
cdrather thangit, the "cdwithgit" row is the likely match. - Check whether the
cdtarget is the working directory itself. If not, that's your cause. - If it is and you still get prompted, check for a trailing
&&with nothing after it, a command over 10,000 characters, or an unquoted glob. All of these fall on the "can't parse it, so ask" side. - If none of that explains it, open
/permissionsand look at the spelling of the saved rules.
Four ways to cut the prompts
1. Start Claude Code inside the repository you want to work in
This felt the most reliable. The directory you start in is the working directory, so a cd to that directory isn't a prompt trigger. If you work across several repositories, I'd split sessions per repository.
2. If you need another directory, add it up front
When you must touch a repository outside the working directory, add it first with --add-dir or additionalDirectories in settings. The docs say a cd into an additional directory is read-only too. But as the table shows, a cd-plus-git move into a different directory may still prompt, even for an added one. I'd test that once before relying on it.
3. Have the commands run separately instead of chained
Skip cd, and run git add and git commit inside the repository as separate commands. Note that alternate forms like git -C <path> add ... may not match your rules: the docs show that a deny rule for Bash(git push *) doesn't catch git -C . push. A different form isn't guaranteed to match the same rule. If you switch forms, add allow rules in the same form.
4. Put it in CLAUDE.md, but don't expect too much
Writing "don't use cd in compound commands" in CLAUDE.md has been tried in the issue comments. One person wrote it in capitals and in memory files and reported only about a 50% reduction. I'd treat it as something that won't be followed every time.
The comments also suggest a PreToolUse hook that looks at the whole command and returns an allow. One comment adds a warning, though: if a hook auto-allows cd x && <read-only> chains, it should also deny destructive chains like cd x && rm -rf ... as its mirror image — otherwise the fast lane becomes a dangerous lane. That is the point I agreed with most.
What I'd avoid
My first thought was that adding Bash(cd *) to allow would quiet things down. But if the prompt comes from the cd-with-git combination, allowing cd doesn't change how that combination is treated, as far as I can read. And a broad allow rule is how you end up not knowing what you permitted.
Don't widen permissions to reduce the number of prompts. I cut the prompts by changing where the work happens, and keep the permissions narrow.
The next time the approval screen appears, read the command it names, character by character — is it git or cd? That alone will tell you whether to touch your settings or change where you start the session.