[BUG] Sandbox git proxy rejects git push updates to existing main with HTTP 403
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?
Environment
- Claude Code on the web (sandboxed sessions)
- Repo: InfoSecAI-Org/career-copilot (private)
- Long-running session — slice-by-slice product development
Bug
The sandbox's git proxy at http://127.0.0.1:<port>/git/InfoSecAI-Org/career-copilot/git-receive-pack returns HTTP 403 with body:
ERR Unable to parse branch information from push data
…on any push that updates the existing main branch. In the same session, under the same auth:
- Pushes to my dev branch (
claude/review-project-docs-xphdS) succeed. - Pushes that create new branches (e.g.
git push origin claude/...:test-push-target) succeed. - Pushes that update
main, regardless of source branch or refspec, return 403. - Branch deletion via
git push origin --delete <branch>also returns 403.
What had been working
Direct fast-forward pushes to main worked six times earlier in the same session (slices 1–7a). The 403 started appearing somewhere around slice 8 with no workflow change on my side.
Confirmed not GitHub-side
- GitHub branch protection on
mainis disabled.GET /repos/InfoSecAI-Org/career-copilot/branches/mainreturnsprotected: false. - 403 response includes
Cf-Cache-Status: DYNAMICandSet-Cookie: Domain=api.anthropic.com— origin is the sandbox proxy, not GitHub.
Verbose curl headers
Workaround
Opening a PR from the dev branch into main via the GitHub UI works.
Question
Is this a regression in the harness, an undocumented per-session limit on main updates, or intended behaviour I should design around? Knowing which would help me pick a long-term cadence (direct push vs PR-merge).
What Should Happen?
Direct git push origin main (a fast-forward from the session's dev branch) should succeed, the same way pushes to the dev branch and to brand-new branches do — or, if updates to main are intentionally restricted in the sandbox, the proxy should return a documented, actionable error such as "main updates require a PR". The actual response is a generic HTTP 403 with body ERR Unable to parse branch information from push data, which is neither documented nor recoverable from inside the sandbox.
Error Messages/Logs
HTTP/1.1 403 Forbidden
Content-Type: application/x-git-receive-pack-result
Content-Length: 78
Server: cloudflare
Body: ERR Unable to parse branch information from push data
Steps to Reproduce
- Open a Claude Code on the web session against a private GitHub repo. (My session was against
InfoSecAI-Org/career-copilot, working on a long-lived dev branchclaude/review-project-docs-xphdS.)
- Have the agent build features slice-by-slice across multiple commits. After each slice, the agent fast-forwards
mainto the dev branch via:git checkout main
git merge --ff-only <dev-branch>
git push origin main
These pushes succeed for the first several slices.
- Continue the same workflow. Somewhere around the 6th-8th main fast-forward in the session,
git push origin mainbegins returning:error: RPC failed; HTTP 403 curl 22 The requested URL returned error: 403
With response body (captured via GIT_CURL_VERBOSE=1):
ERR Unable to parse branch information from push data
- From that point in the session, the rejection is reproducible:
git push origin main→ 403git push origin <dev-branch>:main→ same 403git push origin <dev-branch>:refs/heads/main→ same 403git push origin --delete <any-branch>→ same 403
- In the same session, under the same auth, these continue to succeed:
git push origin <dev-branch>(fast-forwards the dev branch)git push origin <dev-branch>:<new-branch-name>(creates a new branch)
- Confirmed not GitHub-side:
GET /repos/<owner>/<repo>/branches/mainreturnsprotected: falsefor all branches.- The 403 response carries
Cf-Cache-Status: DYNAMICandSet-Cookie: Domain=api.anthropic.com— origin is the sandbox proxy, not GitHub.
- Workaround: opening a PR from dev → main via the GitHub UI and clicking Merge succeeds. So the underlying GitHub auth is fine; only the sandbox proxy's main-update path is rejecting.
I cannot produce a minimal repro project because the trigger appears to be cumulative session state on the proxy side rather than something in the repo content.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
N/A — bug appeared mid-session. The first ~6 fast-forward pushes to main succeeded; then began failing. Same Claude Code build throughout.
Claude Code Version
Claude Code on the web (browser session, no CLI version to query). If a session ID would help, I can provide via Anthropic support.
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
Important context this template doesn't capture cleanly:
- This is Claude Code on the web (the browser-based sandbox), not the local CLI on macOS. The OS / terminal fields above are misleading — Claude executes in an Anthropic-hosted Linux sandbox, not on my Mac. The git proxy at
127.0.0.1:<port>/git/...is part of that sandbox, fronted by Cloudflare withSet-Cookie: Domain=api.anthropic.com.
- The bug is reproducible on demand from inside the sandbox once the proxy state has flipped: every
git push origin mainreturns the same 403 with bodyERR Unable to parse branch information from push data, while pushes to non-main branches and creates of new branches continue to work in the same session under the same auth.
- I cannot produce a minimal local repro because the trigger appears to be cumulative session state inside the proxy.
- Workaround that does work: opening a PR from dev → main via the GitHub UI and clicking Merge succeeds. So the issue is specifically the sandbox proxy's main-update path.
- Repo (private): InfoSecAI-Org/career-copilot. Dev branch: claude/review-project-docs-xphdS. Happy to grant the on-call repo access if that would help.
4 Comments
I'm seeing this, too, and it has broken my specific workflows.
Same issue happening with me – multiple separate Claude Code on Web accounts are now all getting 403.
This should be fixed now.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.