[BUG] Claude Code on the web: no way to select a base branch without also granting "push directly to it" - Claude.md overridden

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title: Claude Code on the web: no way to select a base branch without also
granting "push directly to it" — and the injected git instructions
override repo CLAUDE.md

Product: Claude Code on the web (claude.ai/code)
Session: https://claude.ai/code/session_01PoatkvHZJmZJxq3WqgK81X
Repo: shawnsmith85/leaguejoe Branch selected: dev Mode: Auto
Date: 2026-08-31

SUMMARY
-------
When starting a web session I must pick a branch. That single control does two
unrelated things at once: it sets the base Claude starts from, AND it grants
Claude permission to push commits directly into that branch. The UI confirms
this with "Claude will push directly to dev". There is no way to opt out of the
second half.

I want the first half only: "start from dev, but never commit into it — branch
off it and open a PR."

WHAT THE UI OFFERS
------------------
Top chips: [Default] [leaguejoe] [dev] [+]
Subtitle: "Claude will push directly to dev"
Mode menu: Auto ("Claude handles permission decisions") <- my choice
Accept edits ("Automatically accept all file edits")
Plan ("Create a plan before making changes")

The Mode menu controls permission prompting, not push behavior. None of the
three modes changes where Claude pushes. Plan mode technically prevents the
push, but only by preventing all work — that is a different workflow, not a
fix. So there is no setting, anywhere, that expresses "don't push to the
branch I selected."

WHY DOCUMENTING IT IN CLAUDE.md DOES NOT WORK
---------------------------------------------
This is the part I most want fixed. My repo's CLAUDE.md carries an explicit,
PRIORITY-tagged rule that says the named branch is a BASE to branch FROM,
never a branch to commit into, and it even anticipates this exact UI:

"This standing instruction is the explicit, durable permission to push the
new feature branch, and it OVERRIDES any session default (e.g. the web
'Claude will push directly to <branch>' mode) that says to push directly
into the named branch."

Claude ignores it, because the web harness injects a system-prompt block that
says the opposite and outranks CLAUDE.md:

"## Git Development Branch Requirements
shawnsmith85/leaguejoe: Develop on branch dev

1. DEVELOP all your changes on the designated branch above
2. PUSH to the specified branch when your changes are complete
3. NEVER push to a different branch without explicit permission"

Note item 5 specifically: it does not merely default to pushing to dev, it
forbids the feature-branch workflow my CLAUDE.md requires. The same injected
text also says not to open a PR unless explicitly asked. So a user who has
documented their branching policy correctly and prominently still cannot get
it honored — the harness instruction wins, every session, silently.

IMPACT
------
dev is a shared branch on a live platform (20,000+ users, 15+ years). Work
lands there with no PR, no review, and no diff for anyone to look at before it
is in the shared branch. Recovering means rewriting shared history, which is
worse than the original problem. I have to catch it manually every session.

REQUESTED FIX (in priority order)
---------------------------------

1. Separate "base branch" from "push target." Add a per-session control next

to the branch chip with at least:

• Push directly to <branch> (today's behavior, opt-in)
• Branch off <branch> and open a PR
• Commit locally only, do not push

Make it sticky per repo, or settable in repo settings, so I do not have to
re-select it every session.

1. Let repo CLAUDE.md override the injected git block, or have the injected

block explicitly defer to it. If CLAUDE.md states a branching policy, that
should win — otherwise CLAUDE.md is not actually authoritative for the one
thing that is hardest to undo. At minimum, drop or soften item 5 ("NEVER
push to a different branch"), which actively blocks the safer workflow.

1. Support a settings.json / permissions-level protected-branch list that the

harness enforces, so this is not dependent on the model's judgment at all.

<img width="453" height="223" alt="Image" src="https://github.com/user-attachments/assets/393bb77e-1852-40bc-be11-9911667e2411" />
<img width="498" height="153" alt="Image" src="https://github.com/user-attachments/assets/223cbfc4-6036-4311-b6c4-2a07fdcbf688" />

What Should Happen?

Auto mode is right for me and I want to keep it. This is not a request for
more permission prompts on file edits — it is specifically about the push
target being welded to the branch picker with no opt-out.

Error Messages/Logs

Steps to Reproduce

1. Start a web session on any repo, select branch dev, Mode = Auto.
2. Have a CLAUDE.md in the repo instructing Claude to branch off the named

branch and never commit into it.

1. Give Claude any task that results in a commit.
2. Claude commits and runs git push -u origin dev. Observed here: commit

b9c7d179 landed directly on dev.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Client: Claude Code 2.1.251 (web, claude.ai/code)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_