Allow pushing to the task-assigned branch, not just claude/* branches
Feature Request
Problem
When Claude Code deskopt/web (not CLI) is invoked with a task that specifies a target branch (e.g., via a GitHub issue or PR review workflow), the git proxy restricts pushes to only claude/* branches. This means Claude cannot push directly to the branch it was asked to work on.
In practice, this forces an awkward workaround:
- Claude creates a
claude/*side branch - Pushes fixes there
- Creates a separate PR to merge the side branch into the actual target branch
- The user has to merge that PR manually
The end result is the same commits landing on the same branch, but with extra friction, noise (extra PRs, extra branches to clean up), and confusion for the user.
Proposed Solution
Allow the git proxy to also permit pushes to the branch specified in the task instructions. The proxy already knows which branch Claude is supposed to work on — it's in the task configuration. Allowing pushes to that specific branch (in addition to claude/* branches) would eliminate the roundabout workflow while maintaining safety.
This would not weaken the safety model — Claude still couldn't push to main, other feature branches, or any branch not explicitly assigned. It would just remove an unnecessary restriction on the one branch Claude was told to use.
Current Behavior
- Claude is assigned to work on branch
127-auto-chat-titling(a PR feature branch) - Claude can fetch/checkout that branch
- Claude cannot push to it (403 from proxy)
- Claude can push to
claude/pr-129-review-fixes-KKnEk - User must manually merge or Claude must create a secondary PR
Expected Behavior
- Claude is assigned to work on branch
127-auto-chat-titling - Claude can push directly to
127-auto-chat-titling - No extra branches or PRs needed
Showing cached comments. Read the full discussion on GitHub ↗
9 Comments
Furthermore, until I realized what was going on (Claude was quietly working around the proxy by creating a new claude/ branch to push to), I was losing work done in Claude cloud because I failed to note the new claude/ branches being created.
Additional context from real usage: the workaround of pushing to a
claude/*branch and creating merge PRs is even worse in practice than initially described.When there are multiple rounds of review feedback, each round requires:
claude/*side branchThis happened three times in a single PR review session (PR #129 → PRs #131, plus another manual merge). What should have been "commit and push" turned into 3 extra merge PRs and significant user frustration.
The fix is straightforward: allow pushing to the branch specified in the task instructions, not just
claude/*branches.+1. our repo does not allow
claude/[...]as a branch name and this prevents claude to open PRsAny progress or response on this one appreciated.
Also having issues with this.
+1 on removing this restriction, it makes using Claude outside the CLI impractical which is a real bummer considering using it from the browser/mobile is super convenient.
+1
Same issue here with scheduled tasks on claude.ai/code. Even with "Allow unrestricted branch pushes" enabled for the repository, the session system prompt still injects a claude/* branch constraint ("Develop on branch claude/xxx... NEVER push to a different branch without explicit permission"). This makes the permission setting effectively useless for scheduled tasks that need to push directly to main. The task prompt cannot override this system-level instruction without looking like a prompt injection attempt to Claude itself.
another +1, we use GitHub's restricted branch names to enforce a pattern. Claude will read the error and pick a better branch name, but can't push. I've restored to providing a PAT...