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

Open 💬 11 comments Opened Oct 24, 2025 by coygeek

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 ↗

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