claude-code - 💡(How to fix) Fix [BUG] Sandbox git proxy rejects git push updates to existing main with HTTP 403

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• 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 main is disabled. GET /repos/InfoSecAI-Org/career-copilot/branches/main returns protected: false.
• 403 response includes Cf-Cache-Status: DYNAMIC and Set-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

1. 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 branch claude/review-project-docs-xphdS.)

2. Have the agent build features slice-by-slice across multiple commits. After each slice, the agent fast-forwards main to 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.

3. Continue the same workflow. Somewhere around the 6th-8th main fast-forward in the session, git push origin main begins 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

1. From that point in the session, the rejection is reproducible:

• git push origin main → 403
• git push origin <dev-branch>:main → same 403
• git push origin <dev-branch>:refs/heads/main → same 403
• git push origin --delete <any-branch> → same 403

1. 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)

1. Confirmed not GitHub-side:

• GET /repos/<owner>/<repo>/branches/main returns protected: false for all branches.
• The 403 response carries Cf-Cache-Status: DYNAMIC and Set-Cookie: Domain=api.anthropic.com — origin is the sandbox proxy, not GitHub.

1. 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 with Set-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 main returns the same 403 with body ERR 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.