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 page 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

Don't confuse 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.

The Claude moves worth stealing, by email

Workflows tested on real jobs, sent only when they are worth it. Free.

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.

We haven't run claude --version against the fix ourselves; the steps follow the CHANGELOG. Confirm the number on your machine before you assume you already have the fix.

We don't list upgrade flags, permission flags, or "always allow git" toggles here, because the CHANGELOG names none. 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. We didn't re-test this in the CLI, so run it locally after you upgrade

Field note, checked 2026-09-13: every claim above comes from the CHANGELOG linked in the body. Recheck it before you change your permission rules.

Where to go next

If the issue is commit trailers rather than permission prompts, see How do I turn off Claude Code commit attribution and the Claude-Session trailer?. Nearby release notes: Claude Code 2.1.271-2.1.272.

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

The Claude moves worth stealing, by email

Workflows tested on real jobs, sent only when they are worth it. Free.