[BUG] git push of tags fails with 403 from Claude Code cloud session, despite full GitHub App permissions and no repo protections

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?

Summary

From a Claude Code cloud session (claude.ai/code), git push origin <tag> consistently fails
with HTTP 403 when pushing a tag ref, while pushing branch refs to the same repository,
in the same session, works fine. This previously worked from Claude Code cloud sessions against
this exact repository/environment; it no longer does, with no change made on the repository side.

Environment

• Repo: personal repo
• Session type: Claude Code cloud/web session ("managed remote execution environment")
• Same environment previously used successfully for tag-triggered releases on this repo
• GitHub integration: the "Claude" GitHub App (developed by anthropics), installed on the

account with "All repositories" access

Expected behavior

git push origin v1.3.0 (an annotated tag, pointing at a commit already present on origin/main)
succeeds, the same way it has in prior sessions in this same environment.

Actual behavior

$ git push origin v1.3.0
error: RPC failed; HTTP 403 curl 22 The requested URL returned error: 403
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly

• Immediately prior in the same session, git push origin main succeeded normally.
• Retried the tag push 4x with exponential backoff (2s/4s/8s/16s) per standard guidance for

transient network errors — same 403 every time.

• Tested with a throwaway, non-semver tag name (test-tag-delete-me) to rule out a rule

specific to the v*.*.* pattern — same 403, then deleted locally.

• Retried again in a later turn (after checking repo settings, below) — same 403, not transient.
• The local agent-proxy status endpoint (/__agentproxy/status) showed recentRelayFailures: []

both times, suggesting this is a real HTTP 403 response from GitHub's git smart-HTTP endpoint,
not a local network/proxy-level block.

Things ruled out on the repository side

Checked via the GitHub web UI (screenshots available if useful):

1. Classic protected tags (Settings → Tags): empty. GitHub's own UI additionally reports

"Protected tags have been deprecated" (repo hasn't migrated, but there's nothing to migrate).

1. Repository Rulesets (Settings → Rules → Rulesets): none exist at all — "You haven't

created any rulesets."

1. GitHub App permissions (account Settings → Integrations → GitHub Apps → Claude →

Configure): "Read and write access to actions, checks, code, discussions, issues, pull
requests, repository hooks, and workflows" (i.e. Contents: write, which governs both branch
and tag refs), repository access set to "All repositories."

So there is no repo-side permission or protection that should distinguish branch pushes from
tag pushes for this App installation — yet the behavior differs categorically.

Additional observations

• The GitHub MCP tool set exposed to this session includes read-only tag tools (get_tag,

list_tags, get_release_by_tag) but no tool to create a tag/ref/release — unlike branches,
files, and PRs, which all have corresponding write tools (create_branch,
create_or_update_file, create_pull_request, etc.). If tag/release creation is
intentionally excluded from the tool surface as a safety measure, that's a reasonable product
decision, but it's currently undiscoverable except by hitting the 403 — no tool description
or documentation surfaces this limitation up front.

• This is user-relevant here because the repo's release pipeline

(.github/workflows/release.yml) is triggered purely by push: tags: v*.*.* — there's no
workflow_dispatch fallback — so a cloud session that can push to main but not tags cannot
complete a release end-to-end without the user manually creating the tag/release themselves
via GitHub's web UI.

Impact

Blocks the documented "push with release" workflow (create annotated tag, push, CI builds and
uploads to TestFlight) from being completed inside a Claude Code cloud session, even though it
has previously worked in this same environment/repository. Workaround in the meantime: the user
manually creates the GitHub Release (which creates the tag) via the web UI.

Ask

• Confirm whether cloud sessions are intentionally restricted from pushing tag refs (and if so,

document/surface that clearly, ideally via a typed error rather than a bare 403), or

• If this is a regression/credential-scoping bug (since it previously worked against this same

repo/environment), please investigate why tag-ref pushes are being rejected while branch
pushes with the same credentials succeed.

What Should Happen?

git push origin v1.3.0 (an annotated tag, pointing at a commit already present on origin/main)
succeeds, the same way it has in prior sessions in this same environment.

Error Messages/Logs

Steps to Reproduce

Push a commit with creation of a tag

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

In august

Claude Code Version

2.1.278

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_