Dev containers should declare their network needs before they run

Dev containers and IDE plugins should declare outbound network calls in a visible, machine-readable manifest before they run. Not because every connection is suspicious, but because package indexes, license or vulnerability checks, telemetry, AI requests, remote builds, and private registries are materially different capabilities.

Today, dev-container metadata describes plenty of container behavior, but there is no standard field for intended destinations or purposes. When I open an unfamiliar repository, I should be able to see that its setup wants npm access, a license server, or an AI endpoint, then approve hosts individually, deny telemetry, or continue with networking disabled. A warning that only offers “trust everything” is mostly theater.

Should this declaration live in package metadata, the editor UI, the container runtime, or an operating-system sandbox? I’d like to hear which network access you consider essential, and whether any tools already handle this well.

The manifest is useful, but it cannot be the security boundary. A script can claim “package index” and contact somewhere else, intentionally or because a dependency redirects it. The runtime or OS sandbox has to enforce destinations. Metadata is the review screen; policy enforcement belongs below it.

The distinction between declared capability and actual behavior is doing most of the work here. I would avoid presenting a manifest as evidence that a tool only makes the calls it lists. It is still valuable as an auditable claim, especially if the declaration is signed or tied to a specific version.

Please do not put this only in a JSON file that users never open. The editor should translate it into plain-language choices: “download packages from these hosts,” “send prompts to an AI service,” and so on. Granular prompts are good; six scary dialogs during startup are not.

Offline needs to be a first-class mode, not an emergency after every network request fails. A repository should be able to provide caches or local package sources, then run its build with networking disabled. That makes the choice operational rather than merely informational.

I’d want default-deny for unfamiliar repositories, with temporary approvals scoped to host, process, and session. “The container has internet” is far too broad. Also, a hostname allowlist is not magic if the approved service can accept arbitrary uploads, so the threat model still matters.

The product tradeoff is friction. If approval takes five minutes every time someone opens a sample repository, people will click Allow All. The winning design probably remembers decisions, explains why access is requested, and offers sensible presets for package installation versus telemetry.

For an AI extension, model access is essential if I enabled the feature. Telemetry is not. Those should never arrive as one bundled permission called “network access.” Same for package downloads: let me approve the registry while blocking everything else.

Enterprises will ask for policy export and central enforcement, not just a friendly editor dialog. They need to know whether a remote build, license check, or registry access is permitted across a project. I’d place the declaration in the artifact and enforce it at the workspace or runtime layer.

A possible downside: declarations become another neglected manifest. Maintainers will copy examples, vendors will list broad domains, and users will treat green checkmarks as proof of safety. I still favor the proposal, but the UI should show observed calls alongside declared ones and flag mismatches.

This sounds like a job for three layers because apparently one layer is never enough. Metadata tells me what was intended, the editor asks me, and the sandbox makes the answer stick. Anything less becomes documentation with a button-shaped decoration.

The practical starting point is smaller: standardize categories and destination patterns, then make container startup fail closed when a denied capability is requested. Perfect attribution of every transitive request can wait. Right now most tools cannot even tell me that setup is about to reach the internet.