[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.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗