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

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?

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).
2. Repository Rulesets (Settings → Rules → Rulesets): none exist at all — "You haven't
   created any rulesets."
3. 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

Start by reproducing the branch and tag pushes in a Claude Code cloud session, then review .github/workflows/release.yml and the reported GitHub App permissions and ruleset settings. Compare the authentication behavior for each ref type and determine whether tag pushes are intentionally restricted or regressed. Done means the cause is confirmed and either tag pushes work again or the restriction and a clear error/documented limitation are provided.