Technical Context
I regularly test cloud coding environments and web agents (Jules, Codex/Claude Web, Cursor Web, and similar) on tasks that arise in real projects: installing dependencies, accessing external APIs, spinning up dev services, running migrations. And almost always, I hit the same limitation: the execution container lacks proper network access or has severely restricted access.
In my observations, this doesn't look like a "temporary bug" but a deliberate sandbox policy. Often, only strictly controlled HTTPS requests are allowed at the platform level, without the ability to freely go outbound from the container, without port forwarding, and without the familiar set of network tools we expect in a Linux environment.
Because of this, symptoms are confused with anything: "DNS not resolving", "connection refused", "pip/npm not downloading", "git clone not working", "SDK cannot hit API". For an engineer, this is critical because the agent formally "writes code" but cannot build and verify it the way it's done in CI.
Against this background, GitHub Codespaces truly stands out as a more complete environment: VS Code devcontainer, normal network capabilities, familiar work with package managers and external services. But even there, I’ve seen scenarios where the session sleeps or the connection drops, and this must be accounted for in the workflow architecture.
Business & Automation Impact
I view this not as a developer inconvenience, but as a direct limitation for AI automation in engineering chains. If an agent cannot install dependencies and hit external systems, it turns into a "smart editor" rather than an autonomous task executor.
The teams that win the most are those whose build and tests are already packed into a predictable pipeline: lock-files, private package mirrors, artifacts, caches, infrastructure as code. Those who rely on "internet as a given" and live installation of everything on the fly lose out.
In real implementations, I factor in this limitation immediately. In Nahornyi AI Lab projects, we often separate the contours: the web agent works in a "sterile" environment to generate changes, while execution (build/test/scan) goes to a controlled runner—Codespaces, self-hosted GitHub Actions, GitLab Runner, or Kubernetes job—where the network, secrets, and access policies are configured explicitly.
If a business wants to do turnkey AI automation—from ticket to pull request with green CI—architectural compromises are unavoidable. This requires an AI solution architecture that considers security, compute costs, platform limits, and compliance requirements.
Strategic Vision & Deep Dive
I expect that "no internet in container" will become the standard for mass AI IDEs, not a temporary phase. The reason is simple: as soon as you give an agent free outbound access, you get a new class of risks—from key leaks and SSRF to automated abuse of third-party services.
Therefore, I design solutions so that the agent does not need external internet for most operations. A practical pattern that fits well into AI adoption: pre-built dev images with dependencies, internal registries, proxies with allow-lists of domains, and for integrations—thin "integration gateways" with audit and rate limits.
Another conclusion from my projects: the more you want agent autonomy, the more you need a managed "execution plane". This could be Codespaces for teams already in the GitHub ecosystem, or a separate isolated cluster for companies with higher requirements. In both cases, I prefer explicit AI integration with CI/CD and secret stores, rather than trying to "suffocate" a web IDE to the level of a production runner.
If this seems like a complication, I propose another view: you are simply bringing production infrastructure discipline into the development loop. And that is exactly where the battle for speed is happening now: not "who writes code better", but "who executes changes faster and more securely".
What I recommend doing right now
- Separate generation and execution: the agent generates changes, while build/tests go to a trusted runner with a controlled network.
- Remove dependency on public internet: caches, mirrors, dev images, artifacts, private registries.
- Formalize network policy: allow-list, proxies, audit, minimal rights for tokens.
- Configure environment "liveness": so sessions don't die in the middle of long tasks and break the workflow.
This analysis was prepared by Vadim Nahornyi — lead practitioner at Nahornyi AI Lab for AI implementation and automation of engineering processes based on AI agents. I can quickly assess your current dev process, propose a target AI architecture, and assemble a working loop: from a secure execution plane to a "ticket → PR → CI → deploy" pipeline. Contact me, and we will analyze your case based on the specific limitations of your tools and infrastructure.