›_ Claude Code Issues
Claude Code Issues / #10223

[BUG] Inconsistent Network Behavior and Unclear UX in Default Cloud Environment

Status Open
Maintainer reply None cached
Activity 12 comments · opened Oct 24, 2025

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 "Default Cloud Environment" with "Trusted network access" exhibits critical inconsistencies and a confusing user experience that prevents it from being a functional, ready-to-use environment for common tasks like web scraping.

  1. Inconsistent Network Blocking: There is a fundamental inconsistency in how network restrictions are applied. When attempting to access a non-allowlisted domain (jenni.ai), a curl command from the shell resolves the host and receives an HTTP/2 403 response. However, a Python script using aiohttp (as part of the crawl4ai tool) fails at a much lower level with a DNS resolution error (Temporary failure in name resolution). This inconsistent behavior makes debugging the environment's limitations extremely difficult.
  1. Misleading User Interface: The "Trusted network access" setting (see screenshot) is misleading. The term "Trusted" implies a permissive state, when in fact it enables a highly restrictive allowlist that blocks access to most public domains. This creates a significant gap between user expectation and reality, leading users to believe the environment is broken when it is, by design, simply restricted. The UI does not provide any context about what this setting actually does or link to the list of allowed domains.
  1. Missing Core Dependencies for Fallback Mechanisms: The environment's "universal image" is missing key dependencies required for its own fallback logic. The crawl4ai tool correctly tried to fall back from the missing Docker backend to the native (Playwright) backend, but this also failed because Playwright and its browser dependencies are not pre-installed. The subsequent attempt to install them failed due to the network restrictions mentioned above, creating a catch-22.

What Should Happen?

The cloud environment should be consistent, transparent, and ready for common development tasks.

  1. Consistent Network Failure: All tools and processes should fail consistently when accessing a blocked domain. If a domain is not on the allowlist, all outbound connection attempts to it—whether from curl, Python, Node.js, or any other tool—should fail at the same level (e.g., DNS resolution failure or a clear proxy rejection), not behave differently depending on the tool.
  1. Clear UI and User Guidance: The "Network access" setting in the UI should use clearer language.
  • Rename "Trusted network access" to something more descriptive like "Limited (Allowlisted Domains Only)".
  • The UI should include a tooltip or link that directs users to the documentation listing the allowed domains.
  1. Functional Fallbacks: If a "native" backend like Playwright is a primary fallback for the unavailable Docker backend, its dependencies should be pre-installed on the "universal image." A user should not be required to install core components of a fallback system, especially in a network-restricted environment where such installation is doomed to fail.
  1. Automated Dependency Installation: For a smoother experience, the environment should attempt to auto-detect and run project dependency installations (like make install or pip install) upon startup.

Error Messages/Logs

*   **Python DNS Failure:**
    
    Error fetching https://jenni.ai directly: Cannot connect to host jenni.ai:443 ssl:default [Temporary failure in name resolution]
    
*   **Playwright Install Failure (due to network block):**
    
    Failed to install browsers
    Error: Download failure, code=1
    
*   **Docker Not Found:**
    
    make: docker: No such file or directory
    make: *** [Makefile:48: docker-start] Error 127

Steps to Reproduce

  1. On a mobile device, start a new Claude Code session.
  2. Select the "Default Cloud Environment" and set "Network access" to "Trusted network access".
  3. Use the coygeek/2025-07-01-crawl4ai repository.
  4. Provide the prompt: Scrape https://jenni.ai/ and all its pages. This domain is not on the default allowlist.
  5. Observe Claude's attempts: it will correctly try to run make install, then fail on the Docker backend, then fail to install the Playwright native backend due to network restrictions, and finally fail on the HTTP backend with a Python DNS error.
  6. To confirm the inconsistency, ask Claude to run curl -I https://jenni.ai. Observe that this command does not fail on DNS resolution but instead receives an HTTP 403 response, demonstrating the inconsistent network behavior.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.0.26

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

  • This report is based on the official sandboxing documentation, which clarifies that the network restrictions are an intentional security feature. The core bugs reported here are the inconsistency of that feature's implementation and the poor user experience surrounding it.
  • Claude's agentic reasoning throughout the process was excellent. It correctly identified missing dependencies and attempted logical fallbacks. The failure was entirely due to the environment's configuration and limitations.
  • The attached screenshot shows the UI for configuring the cloud environment, highlighting the "Trusted network access" option that is the source of the user experience confusion.

View original on GitHub ↗

11 Comments

github-actions[bot] · 10 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/1346
  2. https://github.com/anthropics/claude-code/issues/10221
  3. https://github.com/anthropics/claude-code/issues/6388

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

coygeek · 10 months ago

[[BUG]] Cloud Environment Has Inconsistent and Broken Network/DNS Resolution for Python and Node.js

What's Wrong?

The Claude Code on the web cloud environment exhibits critical network inconsistencies that prevent the successful execution of common development tasks, specifically those involving Python or Node.js-based tools that need to download dependencies or access the web.

Even when the environment is set to "Full internet access," the underlying networking is broken for specific runtimes:

  1. Python DNS Resolution Fails: Python's standard libraries (like socket and aiohttp) are unable to resolve any external domains, failing with a Temporary failure in name resolution error.
  2. Node.js-based Installers Fail: Post-install scripts for packages like playwright (which uses a Node.js script) fail to download necessary binaries, even when their CDNs (playwright.azureedge.net) are on the allowlist.
  3. Inconsistent Tool Behavior: Basic shell utilities like curl and pip do have functional network access (likely because they are correctly configured to use a system proxy), while Python and Node.js scripts in the same environment do not. This inconsistency makes debugging the environment's limitations nearly impossible for both the user and the AI agent.
  4. WebFetch Tool Fails: The built-in WebFetch tool fails its own internal safety check because it cannot resolve claude.ai, even when the domain is explicitly added to the "Limited" network allowlist.

The cumulative effect is that the "universal image" is not functional for any task that requires installing dependencies with post-install scripts or running Python code that makes web requests.

What Should Happen?

The cloud environment should provide consistent and functional network access that aligns with the user's selected setting ("Full" or "Limited").

  1. Consistent Networking: All pre-installed runtimes (Python, Node.js, etc.) and shell tools (curl) should have the same level of network access. If curl can connect to a host, Python's socket.gethostbyname should also be able to resolve it.
  2. Transparent Proxy Configuration: If the environment uses a mandatory transparent proxy (as evidence suggests), all standard language runtimes should be pre-configured to use it automatically. A developer should not have to debug DNS-over-proxy issues for standard libraries.
  3. Functional Dependency Installation: A standard pip install or npm install for a package with post-install download scripts (like Playwright) should succeed when network access is set to "Full".
  4. WebFetch Reliability: The WebFetch tool should function correctly in "Limited" mode as long as its required operational domains (e.g., claude.ai) are included in the allowlist.

Error Messages/Logs

  • Python DNS Resolution Failure:

``
socket.gaierror: [Errno -3] Temporary failure in name resolution
``

  • Playwright Browser Install Failure:

``
Failed to install browsers
Error: Failed to download Chromium 140.0.7339.16 (playwright build v1187), caused by
Error: Download failure, code=1
``

  • WebFetch Safety Check Failure:

``
Unable to verify if domain jenni.ai is safe to fetch. This may be due to network restrictions or enterprise security policies blocking claude.ai.
``

  • Initial Docker Not Found (Context):

``
/bin/bash: line 1: docker: command not found
``

Steps to Reproduce

  1. Start a new "Claude Code on the web" session.
  2. Select the repository: https://github.com/coygeek/2025-07-01-crawl4ai
  3. For the environment, select the default or create a new one with "Full internet access".
  4. Provide the following simple prompt:

> First, run make install. This will attempt to install dependencies including Playwright.

  1. Observe the primary failure: The make install command will successfully install Python packages via pip but will fail with a Download failure, code=1 error when the playwright install post-install script runs.
  2. Observe the secondary failure: After the installation fails, give a follow-up prompt to confirm the DNS issue directly:

> Run this python command: python3 -c "import socket; print(socket.gethostbyname('google.com'))"

  1. Observe that this command fails with Temporary failure in name resolution, while curl -I https://google.com would succeed.

Additional Information

  • Crucial Diagnostic Finding: The agent correctly discovered that the environment has HTTPS_PROXY and HTTP_PROXY environment variables set (e.g., HTTPS_PROXY=http://...:15002). This strongly suggests that curl and pip are respecting this proxy, but the Python socket library and the Node.js script used by Playwright are not, leading to the inconsistent behavior.
  • Agent Performance: It's worth noting that the Claude agent's reasoning throughout this process was excellent. It correctly identified missing dependencies, attempted the correct installation commands, and when all execution paths failed, it pivoted to creating a complete set of configuration files and scripts as a final deliverable. The failure is purely environmental, not logical.
  • UX Feedback: The "Limited" network access mode (previously labeled "Trusted") is confusing. It should be made clear that this enables a highly restrictive allowlist, and the UI should provide a link to the documentation listing the default allowed domains.
jsclayton · 9 months ago

Similar issue with Go dependencies:

Bash
go version
Exit code 1
go: downloading go1.25.3 (linux/amd64)
go: download go1.25.3: golang.org/toolchain@v0.0.1-go1.25.3.linux-amd64: Get "https://storage.googleapis.com/proxy-golang-org-prod/d6315236f37e3b3a-golang.org:toolchain-v0.0.1-go1.25.3.linux-amd64.zip?Expires=1763068817&GoogleAccessId=gcs-urlsigner-prod%40golang-modproxy.iam.gserviceaccount.com&Signature=AF1UNJdfIfgVqC%2Fv8CWwS%2BwOt1GixyL6sTf1gxjWOONkY8KqA7a3uEaTmzAmoQd%2F%2BzEYeP1GzrQehUccbOYgBrdWYyBkGgjZMGdqWP%2BVdpjkV4RccbXZUQHjOyLgxD4%2FsFxjoKz%2BKO7n9ElvsqiUJsUjwhk6fj%2F8WS3GDjXhKWdn%2FmdymmKPLXWRWQlq3ptnFgXFBWvy2IsJouxR1alMUAw22cJuA%2F3f%2F0dSsh%2Bpih2IAHrazHNwsNHFBbnQzOaAVDa%2BXNce7rBD2os9cu8rlA30ses1lE8GHJZ8M2FUzI2o9BoUU5s7XvK4Vwb7%2BoGoN4ws%2Fkty5WEhQM2dqnEmiw%3D%3D": dial tcp: lookup storage.googleapis.com on [::1]:53: read udp [::1]:60885->[::1]:53: read: connection refused

I encounter the same failure in the Default environment, in a new environment with Full Network Access, and even in a custom environment where I've explicitly allowed the following in addition to the default list:

go.dev
golang.org
storage.googleapis.com

Not having, or being able to install, the correct tooling is a major blocker to using Claude Code on the Web.

cantino · 8 months ago

I have similar DNS resolution issues.

github-actions[bot] · 7 months ago

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.

stewartadam · 7 months ago

Still occuring

stewartadam · 6 months ago

.

razhangwei · 4 months ago

Adding a related data point from a different surface: I've been hitting the same DNS resolution failure in claude.ai's code execution sandbox (not Claude Code's cloud environment), where pip install fails with Temporary failure in name resolution for pypi.org.

What's notable is the intermittency — the failure is not consistent across sessions. Starting a fresh conversation (which presumably spins up a new sandbox container) often resolves it. This suggests the problem is at the container/instance level rather than a blanket policy, which aligns with the inconsistency described here.

The user-facing experience is particularly confusing because:

  • There's no indication in the UI that the current sandbox instance has a degraded network
  • Claude correctly diagnoses the error and attempts fallbacks, but all fallbacks also fail for the same reason
  • Retrying in a new session silently fixes the problem, with no explanation of why

The core issue this report identifies — inconsistent enforcement + no user visibility — applies equally to the claude.ai sandbox context. A simple session-level network health indicator would go a long way toward reducing confusion.

coygeek · 3 months ago

Checked the current state on 2026-05-07. This issue is still unresolved.

coygeek · 3 months ago

Still relevant as of 2026-05-28. I checked the current docs and this documentation gap still appears unresolved.

coygeek · 2 months ago

Verified against the latest docs; this still appears unresolved.

Showing cached comments. Read the full discussion on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Browse all Claude Code issue topics →