claude/for
Search
Subscribe
Claude CodeUpdated

Why does Claude Code keep asking permission for read-only git commands?

Claude Code 2.1.269 could re-prompt on read-only git Bash after a long session; upgrade to 2.1.270+ for the fix. Do not disable permissions wholesale.

If a long-running Claude Code session started re-prompting for read-only git commands in Bash - git status, git log, git diff, and similar - that was a regression in 2.1.269, fixed in 2.1.270. Upgrade the CLI. It is not a signal to turn off the permission system.

TL;DR. Symptom = read-only git Bash asks again after the session has been up a while. Cause = regression introduced in 2.1.269. Fix = 2.1.270+. Keep normal allow/ask/deny rules; don’t blanket-disable permissions.

Symptom - long session · read-only git · Bash prompts

Typical pattern:

  1. Session starts fine. Read-only git via Bash is allowed (or already approved for the session).
  2. You work for a while - many turns, tools, maybe compaction.
  3. Later, the same class of read-only git Bash commands starts hitting the permission prompt again.

“Read-only” here means inspect-only git usage through the Bash tool - not git commit, git push, or other write/network side effects. The surprise is that inspect commands you already expected to pass start asking again mid-session.

If every new session always asks once for a rule you never allowed, that is normal permission behavior - not this bug. This fiche is about the unexpected re-ask after the session has been running.

Cause - regression in 2.1.269

Anthropic’s Claude Code CHANGELOG documents the fix under 2.1.270:

Fixed read-only git commands in Bash unexpectedly asking for permission after a session had been running for a while (regression in 2.1.269)

So:

VersionRole
2.1.269Introduced the regression
2.1.270Ships the fix

Do not treat forum anecdotes as product truth. Do not conflate this with managed MCP allowlists, sandbox path rules, or other permission surfaces - those are separate systems. The CHANGELOG line is specific: read-only git · Bash · after a while.

Fix - upgrade to 2.1.270+

  1. Check your install version:
    claude --version
    
  2. If you are on 2.1.269 (or anything below 2.1.270 that still shows the mid-session re-prompt), upgrade to 2.1.270 or newer with your usual install path (npm global, native installer, or IDE-bundled CLI - follow current Anthropic docs for your surface).
  3. Start a new session after upgrade so you are not debugging a leftover long-running process on the old binary.
  4. Re-test the same read-only git Bash flow. Mid-session re-prompts for those inspect commands should stop.

[GAP]: claude --version was not available in this authoring environment (CLI not on PATH). Confirm the number on your machine before you assume you already have the fix.

This page does not invent upgrade flags, permission flags, or “always allow git” toggles. Use whatever your install channel already documents.

What not to do

  • Don’t disable all permissions to silence the prompts. That trades a version bug for a much larger blast radius (writes, network, destructive Bash).
  • Don’t invent settings or CLI flags you saw in a tweet. If it isn’t in official docs or the CHANGELOG for your version, treat it as unverified.
  • Don’t rewrite your allow/ask/deny rules as the first move. Upgrade first; only tune rules if prompts remain on 2.1.270+ for commands that truly need a rule.
  • Don’t confuse one allow for a single command with “git is fully open.” Write and push paths should still go through your normal approval habits.

Permissions exist so Claude asks before risky side effects. A regression that over-asks on read-only git is annoying; removing the guardrail is worse.

FAQ

Is this the same as Claude asking for every Bash command?
No. The documented bug is narrower: read-only git through Bash, after the session had been running for a while, regression in 2.1.269.

I still get asked on 2.1.270+ - is the bug unfixed?
Maybe you are still on an old binary in another terminal/IDE host, or the command isn’t read-only, or a deny/ask rule genuinely matches. Confirm claude --version, restart the session, then inspect your permission rules - without wiping them.

Should I set bypass / skip-all approvals?
No for this symptom. Upgrade. Bypass modes are a different product decision and are out of scope for a read-only-git re-prompt bug.

Does upgrading change my project permission rules?
The CHANGELOG fix is about unexpected re-prompts for read-only git Bash. It is not described as resetting your settings files. Keep your existing rules unless you intentionally edit them.

Sources (checked 2026-09-13)

  • Claude Code CHANGELOG.md - 2.1.270 fix line; 2.1.269 called out as the regression source (fetched raw same-day)
  • Version check: claude --version - [GAP] CLI not present in authoring environment; verify locally after upgrade

Field note, checked 2026-09-13: claims above follow dated primary sources linked in-body; re-verify product surfaces before you change permissions or install skills.

Where to go next

See Claude for marketing and Claude Skills.

Also see Create a Claude Code skill and How do I run claude plugin eval when you are packaging or evaluating plugins.

One Claude move in your inbox, every Sunday

Four minutes, tested on a real job, then back to your weekend. Free.