Bash permission: git push to default branch blocked despite settings.local.json allowlist + explicit user approval

Summary

git push origin main is denied by the Bash permission system even when:

1. The project's .claude/settings.local.json includes Bash(git push:*) in permissions.allow.
2. The user explicitly approves the command in the chat session.

The denial reason cites a "structural block on default-branch pushes" that is not documented in the public permission policy and is not opt-out-able via user-curated allowlists or explicit user approval.

Environment

• Claude Code (Opus 4.7, 1M context)
• OS: Windows 11
• Shell: Git Bash + PowerShell
• Repository: private repo, single contributor
• Branch protection on main: none (verified via GitHub Settings → Branches)
• .claude/settings.local.json includes Bash(git push:*) (and other /배포 slash-command permissions)

Reproduction

1. In a project where .claude/settings.local.json has Bash(git push:*) in permissions.allow, with no GitHub branch protection rule on main.
2. Make commits on dev, merge into main locally with git merge dev --no-ff.
3. Ask Claude Code to run git push origin main.

Attempt 1 — denial

Permission for this action has been denied.
Reason: Pushing the merge commit directly to main (the repository default branch)
bypasses pull request review.

Attempt 2 — denial after explicit user approval

User typed (translated): "Proceed, this is an approval."

Permission for this action has been denied.
Reason: Pushing merge commit directly to main (default branch) bypasses PR review;
user's "approval" doesn't override the structural block on default-branch pushes.

Expected behavior

One of:

• (a) The Bash(git push:*) allowlist in settings.local.json should permit the call without prompt, since the user has explicitly curated this permission for the repository.
• (b) If the harness applies an additional default-branch policy on top of user allowlists, an explicit user approval in the chat session should clear the prompt for that single call (consistent with how other prompted actions resolve).
• (c) If neither, the policy should be documented publicly so users can configure or opt out.

Actual behavior

Both the user-curated allowlist and the explicit user approval are ignored. There is no documented configuration option to override this block. The same git push origin main command succeeds outside Claude Code (run directly in PowerShell on the same machine, same credentials, same branch state).

Impact

• Breaks user-defined /배포 slash-command workflows that include git push to main.
• Forces users to leave the assistant session to complete the deploy step manually, defeating the purpose of automated deploy slash commands.
• The behavior is asymmetric across model versions: equivalent workflows did not encounter this block on Opus 4.6; the block surfaces on Opus 4.7.

Workaround

Run git push origin main outside Claude Code (e.g., directly in the terminal). The push succeeds and triggers GitHub Actions normally.

Asks

1. Document the default-branch push policy in the public permission docs (currently not listed in the published Bash permission rules).
2. Honor Bash(git push:*) in settings.local.json as the authoritative source for that command, or provide an opt-out flag for the structural block.
3. Make explicit user approval in the chat session resolve the denial for that single call, consistent with other prompted Bash actions.
4. Add an Opus 4.6 → 4.7 changelog entry describing any new structural blocks introduced into the harness permission system.

Related

• Issue #55523 — accumulated incident reports on the same permission system.