[BUG] Git push via local proxy returns HTTP 403, forcing GitHub-MCP fallback with content drift

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 web
Session-injected git remote: http://local_proxy@127.0.0.1:<port>/git/<owner>/<repo>
Proxy upstream is api.anthropic.com (confirmed via Cloudflare headers + Domain=api.anthropic.com cookie in verbose curl trace)
Symptom:

Every git push against the proxy-injected remote returns:

HTTP/1.1 403 Forbidden
Request-Id: req_011CaxdSJqRA8hPpkwL24rAM
git fetch / ls-remote / pull (read paths) all work fine. Only git-receive-pack is blocked. Retried with exponential backoff (2s/4s/8s/16s) — no transient recovery. Persisted across the full session.

Impact / workaround used:

The only available push path becomes mcp__github__push_files / create_or_update_file. That works but requires the model to embed full file contents inline in the tool-call parameter. For one 1255-line C# source file in this session, the JSON encoding pass collapsed \u2014 / \u2192 / \u2713 / \u2717 / \u26d4 escapes into their actual Unicode characters (the 8-hex \U0001F4B0 survived). The file still compiles — C# treats both forms identically — but the blob SHA diverges from the local file and the diff balloons cosmetically.

Total wall-clock cost for what should have been one git push: about 30 minutes of back-and-forth (multiple retry rounds, content reconstruction, integrity verification, sync gymnastics).

Expected:

git push works on a session where git pull works. The MCP fallback is a fine secondary path but it shouldn't be the only path for write operations.

Asks:

If the 403 is a deliberate write-block policy, please document it so I stop retrying and immediately route to MCP.
If it's accidental — proxy mode mismatch, missing auth header on the push path — please fix.
Consider making mcp__github__push_files accept a local-file-path reference instead of inline content, so write parity doesn't depend on model reproduction fidelity for large files.

What Should Happen?

Git push via proxy should work.

Error Messages/Logs

Steps to Reproduce

Environment:

Claude Code on web
Session-injected git remote: http://local_proxy@127.0.0.1:<port>/git/<owner>/<repo>
Proxy upstream is api.anthropic.com (confirmed via Cloudflare headers + Domain=api.anthropic.com cookie in verbose curl trace)
Symptom:

Every git push against the proxy-injected remote returns:

HTTP/1.1 403 Forbidden
Request-Id: req_011CaxdSJqRA8hPpkwL24rAM
git fetch / ls-remote / pull (read paths) all work fine. Only git-receive-pack is blocked. Retried with exponential backoff (2s/4s/8s/16s) — no transient recovery. Persisted across the full session.

Impact / workaround used:

The only available push path becomes mcp__github__push_files / create_or_update_file. That works but requires the model to embed full file contents inline in the tool-call parameter. For one 1255-line C# source file in this session, the JSON encoding pass collapsed \u2014 / \u2192 / \u2713 / \u2717 / \u26d4 escapes into their actual Unicode characters (the 8-hex \U0001F4B0 survived). The file still compiles — C# treats both forms identically — but the blob SHA diverges from the local file and the diff balloons cosmetically.

Total wall-clock cost for what should have been one git push: about 30 minutes of back-and-forth (multiple retry rounds, content reconstruction, integrity verification, sync gymnastics).

Expected:

git push works on a session where git pull works. The MCP fallback is a fine secondary path but it shouldn't be the only path for write operations.

Asks:

If the 403 is a deliberate write-block policy, please document it so I stop retrying and immediately route to MCP.
If it's accidental — proxy mode mismatch, missing auth header on the push path — please fix.
Consider making mcp__github__push_files accept a local-file-path reference instead of inline content, so write parity doesn't depend on model reproduction fidelity for large files.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

claude-opus-4-7 (Opus 4.7, 1M context). Knowledge cutoff January 2026.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_