How to Run a Coding Agent With No Outbound Network Access

A coding agent is software that reads instructions, edits code, and runs tools such as tests or compilers. To run one with no outbound network access, block connections from the environment where the agent runs and from any programs it starts, then provide all required files and tools in advance. “Outbound” means a connection initiated from that environment to another network destination.

An agent container might have no internet access while a separate service still sends its prompts and code to a hosted model. A genuinely disconnected run keeps the agent, the service that runs the model and produces its answers, and any other services handling task data inside the same isolated environment. That requires preloading dependencies and tools, enforcing the network restriction outside the agent itself, and testing that the restriction works.

Decide what “offline” covers

“No outbound access” can describe different arrangements. You might block only shell commands the agent launches, block the entire container or virtual machine (VM), or disconnect every component that handles the task. A VM is a software-defined computer that runs its own operating system and can have separate rules for network traffic.

State the boundary precisely. If a model running on a provider’s servers receives prompts or source code, the agent runtime might be isolated, but the overall workflow is not fully disconnected. For example, Claude Code’s network requirements describe access to Anthropic services, and hosted agent products can have separate controls for model calls, tools, and other services. A product’s “network off” setting therefore needs to be understood in the context of what it controls.

For strict disconnection, run a local model inside the same isolated boundary as the agent. Ollama’s API documentation describes running a model locally through a service on the machine. That provides a way to keep model requests local, but it does not prevent other programs on that machine from using the network. Enforce the boundary separately.

Stage everything before disconnecting

Prepare the agent’s inputs in a connected environment used to gather and prepare files, then transfer them into the offline environment. Include the repository, compiler, and test tools. Also transfer package dependencies and agent plugins, along with container images and model files. A missing dependency can make a build or test fail, or lead an operator to reconnect the runtime to download it.

Pin dependency versions and keep a manifest, or list, of the transferred files and other artifacts. Recording hashes gives reviewers a way to check that files arriving in the offline environment match the files prepared in staging. These controls are practical measures; they do not constitute a universal transfer standard. Check where each artifact came from and whether its license permits use: disconnecting the agent prevents live downloads during the run, but it does not validate files acquired earlier.

Run the agent against a dedicated working copy of the repository, and give it only the files and write access the task needs. Avoid mounting a broad home directory or exposing cloud credentials, production secrets, or privileged host sockets by default. Review patches and logs before transferring them out, because outputs can contain sensitive data.

Block network access at the runtime boundary

For a containerized run, Docker’s --network none isolates the container’s network stack. Docker documents that the container has only its own loopback interface in this mode. For example:

docker run --rm -it \
  --network none \
  --mount type=bind,src="$PWD",dst=/work \
  --workdir /work \
  IMAGE \
  YOUR_AGENT_COMMAND

Replace IMAGE and YOUR_AGENT_COMMAND with the prepared image and agent command. The bind mount makes the current directory available at /work; use a dedicated checkout so the agent cannot modify unrelated files. The network option applies to the container, not the host or the rest of the deployment. A host-level or hypervisor-level rule adds a separate enforcement point.

The container’s loopback address lets programs inside it reach services inside that same container. A model server running on the host is not automatically reachable there. For a disconnected run, place the local model service within the same isolated VM or deliberately configure a local connection inside that boundary. Do not switch to host networking just to make the model reachable, because that changes the network isolation.

Build-time network access needs separate attention. Docker’s Dockerfile reference supports RUN --network=none for an individual build step. For example, a build can install a package from a staged wheel directory:

RUN --network=none pip install --find-links wheels mypackage

This tests that the step has its required files locally. It does not establish that earlier image pulls or other build steps happened without network access.

Apply Kubernetes policies carefully

Kubernetes NetworkPolicy rules can block egress, or traffic leaving selected pods (groups of one or more containers). A policy that selects all pods in a namespace, a Kubernetes grouping for resources, and declares egress without allowing any egress rules is a common default-deny pattern:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress

The Kubernetes NetworkPolicy documentation explains that DNS requests, which look up network addresses from names, are blocked by default under this policy unless a rule permits access to cluster DNS. It also says permissions from matching policies are additive, so another policy that allows traffic can create an egress path. Review every policy selecting the agent pod.

NetworkPolicy filters traffic at layer 4 by transport protocol and port. Enforcement details for some protocols can vary by network plugin. Confirm how the cluster’s network plugin applies the policy, and use infrastructure-level controls when the requirement demands stronger isolation than the pod policy alone establishes.

Treat agent settings as one control

Built-in agent settings can simplify configuration, but their scope depends on the product. OpenAI’s agent security documentation describes network behavior for specific Codex interfaces and separately discusses hosted search, apps, and MCP integrations. GitHub documents that its Copilot cloud-agent firewall covers processes launched through its Bash tool, while some setup steps and MCP server processes fall outside that scope. Its firewall documentation also describes potential bypass limitations.

An allowlist, or list of approved domains, permits selected connections and therefore restricts connectivity rather than blocking all outgoing traffic. Allowing package registries or model endpoints can make a workflow easier to maintain, but it also creates permitted routes and requires someone to maintain the list. Choose that approach only when selected external services are acceptable and the policy covers every relevant process.

Verify from the agent’s environment

Test from the same container, VM, or pod where the agent runs. A setting shown in a user interface does not prove that the effective network boundary blocks all routes. Check that the policy actually applies, then attempt representative outbound connections by hostname and direct IP address. Test IPv4, IPv6, and DNS where those protocols exist in the environment.

Also exercise subprocesses and enabled tools. Include setup commands, extensions, and MCP servers in those tests. Check network logs for attempted and denied connections on the host, hypervisor, or cluster. Look for alternate paths, including proxies and sidecars (helper containers that run alongside the agent). Check for host networking too. Repeat the tests after recreating or updating the runtime, because configuration changes can alter the effective boundary.

A failed network test alone does not prove complete isolation. Confirm the enforcement configuration at the infrastructure layer as well as the agent’s runtime, and document what the test covered.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com