[BUG] Claude Code on the Web .NET SDK binary downloads blocked by proxy even with "All domains" network access enabled

Maybe related: git push is failing for me on Claude Code web as of about an hour ago and will not work for any sessions. Similar proxy errors are printed.

This also affects dotnet restore as NuGet package endpoints are blocked, making Claude Code unusable for Dotnet coding.

The build environment has network restrictions that prevent local build/test verification: when attempting to restore NuGet packages, requests to api.nuget.org are routed through a proxy server at http://21.0.0.139:15004/ which returns 401 Unauthorized (missing proxy credentials), and when attempting to bypass the proxy entirely by clearing proxy environment variables, direct HTTPS connections to NuGet fail with "Resource temporarily unavailable" indicating outbound HTTPS is blocked without the proxy.

This creates a catch-22 where NuGet package restoration is impossible locally - the proxy requires authentication credentials we don't have, and direct access is blocked by network policy.

Raw log example:

Determining projects to restore...
  Restored /home/user/JIM/JIM.Functions/JIM.Functions.csproj (in 505 ms).
/home/user/JIM/JIM.Utilities/JIM.Utilities.csproj : error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json. [/home/user/JIM/JIM.sln]
/home/user/JIM/JIM.Utilities/JIM.Utilities.csproj : error NU1301:   The proxy tunnel request to proxy 'http://21.0.0.139:15004/' failed with status code '401'."

Seems obsolete url used, the CDN used already moved to new url builds.dotnet.microsoft.com

https://devblogs.microsoft.com/dotnet/critical-dotnet-install-links-are-changing/

This makes grade/maven unusable in Java builds as well. This would be a huge fix to allow unit tests to run in Claude Code before digging in manually.

I'm sure there are better options than this workaround but it gets dotnet restore to work for me. I'll try to circle back and look into this more if I get a chance—in the meantime:

#!/usr/bin/env bash
set -e

SOLUTION_PATH="${1:-.}"
DOTNET_VERSION="${2:-10.0}"
LOCAL_PROXY_PORT=18080

echo "=== Installing .NET SDK $DOTNET_VERSION ==="
curl -fsSL https://dot.net/v1/dotnet-install.sh | bash -s -- --channel "$DOTNET_VERSION"
export PATH="$HOME/.dotnet:$PATH"
dotnet --version

echo "=== Creating proxy relay script ==="
cat > /tmp/proxy_relay.py << 'EOF'
#!/usr/bin/env python3
import os, socket, threading, base64
from urllib.parse import urlparse

upstream_url = os.environ.get('HTTPS_PROXY', '')
parsed = urlparse(upstream_url)

UPSTREAM_HOST = parsed.hostname
UPSTREAM_PORT = parsed.port or 8080
PROXY_USER = parsed.username or ''
PROXY_PASS = parsed.password or ''

auth_b64 = base64.b64encode(f"{PROXY_USER}:{PROXY_PASS}".encode()).decode()
LOCAL_PORT = int(os.environ.get('LOCAL_PROXY_PORT', 18080))

def handle_client(client_socket):
    try:
        request = client_socket.recv(65536)
        if not request:
            client_socket.close()
            return

        upstream_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        upstream_socket.connect((UPSTREAM_HOST, UPSTREAM_PORT))

        lines = request.decode('utf-8', errors='ignore').split('\r\n')
        new_lines = [lines[0], f"Proxy-Authorization: Basic {auth_b64}"] + lines[1:]
        upstream_socket.send('\r\n'.join(new_lines).encode())

        def forward(src, dst):
            try:
                while True:
                    data = src.recv(65536)
                    if not data:
                        break
                    dst.send(data)
            except:
                pass
            finally:
                src.close()
                dst.close()

        t1 = threading.Thread(target=forward, args=(upstream_socket, client_socket), daemon=True)
        t2 = threading.Thread(target=forward, args=(client_socket, upstream_socket), daemon=True)
        t1.start()
        t2.start()
        t1.join()
        t2.join()
    except Exception as e:
        print(f"Error: {e}")
        client_socket.close()

def main():
    server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    server.bind(('127.0.0.1', LOCAL_PORT))
    server.listen(100)
    print(f"Proxy relay on 127.0.0.1:{LOCAL_PORT} -> {UPSTREAM_HOST}:{UPSTREAM_PORT}")

    while True:
        client_socket, _ = server.accept()
        threading.Thread(target=handle_client, args=(client_socket,), daemon=True).start()

if __name__ == '__main__':
    main()
EOF

echo "=== Starting proxy relay ==="
LOCAL_PROXY_PORT=$LOCAL_PROXY_PORT python3 /tmp/proxy_relay.py &
PROXY_PID=$!
sleep 2

if ! kill -0 $PROXY_PID 2>/dev/null; then
    echo "ERROR: Proxy relay failed to start"
    exit 1
fi
echo "Proxy relay running (PID: $PROXY_PID)"

# Kill proxy on script exit
trap 'kill $PROXY_PID 2>/dev/null' EXIT

echo "=== Running dotnet restore ==="
env -i PATH="$HOME/.dotnet:$PATH" \
    HOME="$HOME" \
    HTTPS_PROXY="http://127.0.0.1:$LOCAL_PROXY_PORT" \
    HTTP_PROXY="http://127.0.0.1:$LOCAL_PROXY_PORT" \
    dotnet restore "$SOLUTION_PATH"

echo "=== Done ==="

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Still happening, still a blocker for .net development

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

I also have a similar issue:
Google Drive and Sheets APIs return 403 Forbidden from Claude Code web environment.
but authorization is OK..

Evidence
https://www.googleapis.com/discovery/v1/apis → 200 OK
https://oauth2.googleapis.com/tokeninfo → 200 OK
https://sheets.googleapis.com/v4/spreadsheets/...→ 403 Forbidden
https://www.googleapis.com/drive/v3/files/... → 403 Forbidden

403 occurs with AND without authentication
Response is HTML error page, not JSON API error
No X-Proxy-Error header - request reaches Google, so not a proxy error
OAuth token validation works, credentials are valid

Google blocks Drive/Sheets API access from Anthropic's egress IP range. Public APIs (Discovery, OAuth) work; user-data APIs (Drive,Sheets) are blocked, is what I tihnk it is the prioblem

Codex and Github copilot supports this, why cant claude? I need this.

I've packaged up a plugin that will allow easy installation of a workaround for the nuget issue here: https://github.com/logiclabs/dotnet-nuget-proxy-skill

This performs a .NET SDK install and starts a proxy bridge, which is then used by a nuget authentication provider to workaround the current authentication issues with nuget and claude code web environment. Once added to a repo, it will run at the start of every Claude Code web session, to ensure the .NET environment is working.

This is similar to the python relay solution above: https://github.com/anthropics/claude-code/issues/11897#issuecomment-3621337027

I'm also seeing this in Cowork. Adding specific domains to the "Additional allowed domains" list on the Capabilities settings page doesn't work. The domains show as saved, but requests to those domains still return EGRESS_BLOCKED.

https://github.com/anthropics/claude-code/issues/30112 was also reported. Seems pervasive.

Still seeing this.

ALL network egress is blocked in Cowork, not just .net related domains and Allow network egress allow list is being ignored.

This is with a fresh MacOS install, Fresh Claude.app install, and ALL DOMAINS selected as the allow list. No VPN. Claude Pro subscription.

Allow network egress

Give Claude network access to install packages and libraries in order to perform advanced data analysis, custom visualizations, and specialized file processing. Monitor chats closely as this comes with security risks.

Domain Allow List: ALL DOMAINS

Verified and reproducible bug on: Claude 1.2.234 (2d1855) 2026-04-01T07:58:22.000Z

It seems the Egress settings are ignored in the desktop app at least on MacOS in Claude 1.2.234.

I just managed to step around this bug by setting the domain allow list setting to 'All Domains' within network egress, then starting a new conversation thread (in Claude Code on the Web)—hoping there's a fix soon, though, since this doesn't feel very safe.

Same issue, macOS, All domains setting has no effect