Two cloud coding agent products document their network controls in public. Codex cloud keeps agent internet access off by default and offers an allowlist plus HTTP method limits. Claude Code on the web runs in a cloud environment that controls network access, with a Default environment using trusted network access. Pick the narrowest setting that lets your tasks finish.
Why internet access is the main dial
A cloud coding agent works in a container away from your laptop. It clones your repository, edits code, runs tests and proposes a change. The container's network access decides two things: whether it can fetch dependencies, and whether anything inside could be sent out. For buyers, that makes network settings the single most useful control to understand, and the easiest to compare across vendors using the questions in what is a remote sandbox.
This post names two platforms because both publish their settings. It makes no ranking. Details below come from the documentation pages fetched on 19 October 2026, and vendors change these pages, so verify before you rely on them.
What the Codex cloud documentation says
The Codex cloud page (marked legacy in the docs navigation) describes the flow. When you submit a task, Codex creates a container and checks out your repository at the selected branch or commit. It runs your setup script, applies your internet access settings, and then the agent runs terminal commands in a loop, edits code and runs checks. When it finishes, it shows its answer and a diff, and you can open a pull request or ask follow-up questions.
On internet access, the page says setup scripts run with internet access, while agent internet access is off by default. You can enable limited or unrestricted access per environment. The internet access page lists the choices:
| Setting | What it does |
|---|---|
| Off | Completely blocks internet access |
| On with allowlist | Allows access to listed domains only |
| Allowlist presets | None (start empty), Common dependencies, or All (unrestricted) |
| Allowed HTTP methods | Optionally restrict to GET, HEAD and OPTIONS, blocking POST, PUT, PATCH, DELETE and others |
The method restriction is a useful idea for any agent: reading from the internet is lower risk than writing to it, and blocking write methods makes it harder to push data out.
What the Claude Code cloud documentation says
The Claude Code page on cloud sessions says a cloud session runs on infrastructure Anthropic manages by default, or on your organization's self-hosted environment when routed there. Every session runs in a cloud environment, described as the saved configuration that controls network access, environment variables and setup scripts. If you have none, onboarding sets up a Default environment with Trusted network access. The page says sessions can start from the browser, the mobile app, the desktop app by selecting Cloud, the terminal with a cloud flag, or from routines.
It also says GitHub access works through a GitHub App or a token sent from the terminal, with different repository reach for each, and that cloud sessions count toward plan usage limits.
Comparing without ranking
| Question | What to ask or check |
|---|---|
| Default network posture | Off, trusted list, or open? Verify in your own environment |
| Granularity | Per environment? Per domain? Per HTTP method? |
| Setup phase versus agent phase | Does setup get more access than the agent? |
| Who can change it | Admins only, or any developer? |
| Visibility | Can you see which hosts were contacted? |
| Self-hosted option | Can you run the environment inside your network? |
The two products differ in vocabulary more than in the questions you should ask. Both separate an environment configuration from the individual task, which is good for review: you approve an environment once, then tasks inherit it.
Step by step: a safe starting configuration
- Start with network off, or the narrowest preset, for the first pilot repository.
- Run a representative task and note which dependencies failed to install.
- Add only the domains those installs need, and write the reason beside each.
- If methods can be restricted, allow only read methods unless a task needs more.
- Keep secrets out of the agent phase wherever the product allows it.
- Log which domains the agent actually contacted over a week and prune the list.
- Review the list monthly and after any product update.
A worked example
A team enables a cloud agent on a service repository. The first task fails because the package manager cannot reach its registry. The team adds the registry domain from the common dependencies preset rather than switching to unrestricted. The second task wants to call a documentation site for an API example. The team declines, since the documentation can be pasted into the repository. After a week the allowlist has four entries, each with an owner and a reason.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate checks a proposed change before it can merge, which is the control that sits after the agent's sandbox.
Where Safeguard fits
An agent's pull request still has to pass your gates. Safeguard's policies and gates, dependency scanning and reachability analysis can check what the agent proposes, and its autonomous remediation with fix PRs is off by default with every category on Manual. The Safeguard CLI can also write code, and a Local agent and a Cloud agent are listed as Available on the download page, so the same network questions apply there.
Quick check
Is an allowlist always safer than off?
No. Off is the narrowest setting. An allowlist is a controlled opening for tasks that cannot finish otherwise.
Why restrict HTTP methods?
Reads are lower risk than writes. Blocking methods such as POST and PUT makes it harder to send data out, though it does not remove the need for an allowlist.
Do these pages stay accurate?
Not necessarily. Vendors update their documentation and defaults, so confirm in your own settings and note the date you checked.
Sources
- Codex cloud (legacy) documentation
- Codex cloud internet access
- Use Claude Code in the cloud
- Safeguard download page
Last reviewed: 19 October 2026.
