[BUG] Cloud session network access settings are silently ignored for GitHub

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?

In a cloud session, the environment's Network access setting has no effect on
GitHub API requests. Setting Full, or adding api.github.com under Custom,
changes nothing: requests to /repos/{owner}/{repo}/... for a repository not
attached to the session still return HTTP 403 from the GitHub proxy.

There is no error, no warning and no hint. A custom domain entry is accepted
and then has no effect.

The documented behaviour is that the GitHub proxy applies "independent of the
environment's access level". That design decision is not what this report
disputes. What is defective is that the control does not say so, and accepts
input it will not honour:

• Full is labelled "Unrestricted internet access for maximum flexibility". It

is not unrestricted. GitHub is carved out of it.

• Custom is labelled "Create a list of allowed domains". An allowlist with

undocumented carve-outs is not an allowlist. Entering api.github.com is
accepted silently and does nothing.

Silently ignored configuration is the defect. A setting that takes input and
discards it for certain targets, without saying so, sends users to debug a
problem the interface told them they had already solved. I created a separate
environment specifically so as not to alter my Default one, then worked through
the settings there. That effort was spent on a control that cannot work by
design.

What Should Happen?

Either of these resolves it:

1. The setting is honoured for read-only GitHub API requests, or
2. the interface states the carve-out at the point where the setting is made:

reject or warn when a GitHub domain is entered under Custom, and label Full
so that it does not claim to be unrestricted.

Error Messages/Logs

HTTP/1.1 403 Forbidden

{"message":"GitHub access to this repository is not enabled for this session. Use add_repo to request access. If add_repo answers that read access is already available and you need GitHub API or write access, call add_repo again with access:\"push\" to attach the repository with credentials.","documentation_url":"https://docs.anthropic.com/en/docs/claude-code/github-actions"}

No GitHub response headers are present (no x-accepted-github-permissions, no
rate limit headers), so the request does not reach GitHub.

Steps to Reproduce

1. Create a cloud environment (I created a separate one so as not to alter

Default).

1. Set Network access to Full. Start a cloud session.
2. In the session, run:

gh api repos/coollabsio/coolify/issues/11945
or the equivalent curl against api.github.com.

1. Observe HTTP 403 with the body shown above.
2. Repeat with Network access set to Custom and api.github.com added to the

domain list. Same result, and no warning that the entry has no effect.

1. Repeat with Trusted. Same result.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Not a client version regression: the change is server side. Read-only GitHub API access from cloud sessions worked on 2026-10-05 and failed on 2026-10-06.

Claude Code Version

2.1.300 (Claude Code), the version running in the cloud session

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Non-interactive/CI environment

Additional Information

Related documentation gap: the docs state the rule but not its effect. The
"Repository scope" bullet at
https://code.claude.com/docs/en/cloud-environments#github-proxy illustrates it
with a setup script downloading release assets. Nothing on that page says that
read-only API access to public repositories you do not own no longer works. A
reader checking the page beforehand would not predict the behaviour above.

Confirmed with Anthropic Support (conversation 215476262277724). Support also
checked the changelog entries for 2026-10-05 and 2026-10-06 and confirmed that
this change is not listed there.

On the Terminal/Shell field: the defect occurs in a cloud session, which has no
interactive terminal. The session runs non-interactively on Ubuntu 24.04.5 with
bash, so "Non-interactive/CI environment" is the closest option in the list.

A second, separate defect in the same area is filed as #<Nummer von Issue 2>.