[BUG] GitHub proxy 403s release-asset downloads in cloud sessions, breaking builds

Status Open
Reported on v2.1.211
Maintainer reply None cached
Activity 2 comments · opened Jul 17, 2026

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?

The GitHub proxy scopes release-asset downloads to the session's own repos, like API requests (#78277). This is documented: "The proxy limits GitHub API and release-asset requests to repositories attached to the session, regardless of the environment's network access level. Setup scripts that download release assets from unattached repositories return a 403." And it breaks any build whose toolchain fetches prebuilt artifacts from GitHub releases, a mainstream pattern: Dart native-assets hooks as here, plus the uv and npm cases in #19512's thread.

Concrete case: package:sqlite3 ≥ 3.x (the standard Dart/Flutter SQLite binding, used via drift) downloads a prebuilt libsqlite3.so from its GitHub release on simolus3/sqlite3.dart. In a session on my fork chrisbobbe/zulip-flutter, the proxy 403s that download, so flutter test cannot build at all; the failure surfaces, confusingly, as a hash mismatch (explained with the logs below).

Aggravating factors:

  1. Every apparent exit is closed. The environment's network policy allows GitHub (it's in the default package-managers list), but the scoping applies regardless; the docs even note it applies in setup scripts, where no in-session workaround is possible. The 403 says to use add_repo, but add_repo refuses repos from a different owner (output below), and the 403's documentation_url resolves to the Claude Code GitHub Actions page, which doesn't cover session scoping (and isn't reachable from inside a session anyway: docs.anthropic.com is blocked there, x-deny-reason: host_not_allowed). add_repo's other suggestion, starting a new session with the dependency's repo as the source, doesn't fit the problem: the build just wants to fetch an artifact, like any package-manager download.
  2. It's a regression: #19512 reported this in January; its repros began passing in early February and it was closed as completed (now locked, inviting a new issue). The mid-2026 proxy rework (see #76248) re-introduced the block, now as documented behavior.

What Should Happen?

Unauthenticated GETs of public release assets pass through whenever the network policy allows github.com: release-asset downloads are package-manager traffic, not repo access, and the policy already expresses the user's intent.

Failing that: at least stop advising add_repo in cases it cannot help with (as proposed in #78277).

Error Messages/Logs

$ curl -sS -i 'https://github.com/simolus3/sqlite3.dart/releases/download/sqlite3-3.3.4/libsqlite3.x64.linux.so'
HTTP/1.1 403 Forbidden
Content-Type: application/json; charset=utf-8
Content-Length: 195

{"message":"GitHub access to this repository is not enabled for this session. Use add_repo to request access.","documentation_url":"https://docs.anthropic.com/en/docs/claude-code/github-actions"}

What `flutter test` then reports:

  Bad state: Hash of downloaded file libsqlite3.x64.linux.so is
  797b23b1a4b7cbba3ffd7d4bca663200fed9362630d0aa340e8480a3ba8f8052, expected
  e184f6ba2b7a3440e272df64c6d038de5c7b1a997b7c2f9341164602f9bdf024.
  Building assets for package:sqlite3 failed.

(The "actual" hash there is the sha256 of the 403 JSON body: the hook hashed the
error response it received. Checking the status code is package:sqlite3's bug to
fix, but even a clean "HTTP 403" would leave the dead ends above; nothing in the
failure points at network policy.)

add_repo (simolus3/sqlite3.dart), in the same session:

  cross-tier adds are not supported in v1: requested "simolus3/sqlite3.dart" but
  session already has repos from owner(s) [chrisbobbe]. Start a new session with the
  requested repo as the initial source, or add a repo from the same owner as the
  existing sources

Steps to Reproduce

  1. In any web session whose environment allows GitHub (it's in the default package-managers list), curl a public release-asset URL from a repo not attached to the session (e.g. the one in the logs above). Result: 403 with the "not enabled for this session" JSON.
  2. Call add_repo for that repo: refused, cross-tier.
  3. How this breaks builds: in an environment provisioned for Flutter, run flutter test on a project depending on package:sqlite3 ≥ 3.x (e.g. zulip/zulip-flutter). Its build hook fetches that asset, and the failure surfaces as the hash-mismatch error above.

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

unknown; release-asset fetches worked from early February (per #19512's closure) until the mid-2026 proxy rework

Claude Code Version

2.1.211

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

  • Related: #78277 (same repo-scoped proxy, different fix surface: repo-data reads vs. artifact fetches; a release-asset passthrough could ship independently). Same genre: #11897 (.NET binaries), #34840 (Gradle plugins), #10307 (crates.io).
  • Here the breakage is workaroundable only because package:sqlite3 has a use-the-system-SQLite escape hatch (pubspec user-defines source: system), applied per-session by a SessionStart hook, with the pubspec edit kept out of commits (git update-index --skip-worktree). Most release-asset-fetching packages have no such hatch.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗