egressAllowlist in environment.json is not enforced

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

For a repository-managed Cloud Agent environment, egressAllowlist and egressMode in committed .cursor/environment.json show up in the environment configuration (e.g. in environmentJson), but they are not applied to outbound network policy on running agents or environment builds.

In the dashboard we use “Defaults + Environment Allowlist” with an empty UI Network Allowlist (allowlist defined in the repo file). On the VM, effective egress looks like Cursor defaults only: hosts we added only via egressAllowlist in JSON are still blocked (typical symptom: curl TLS/connection errors), while common default destinations work.

Expected: Defaults plus repo egressAllowlist are enforced on new pods/builds.

Actual: Repo allowlist is recorded in config but missing from effective egress, which breaks install steps that need hosts outside the default set.

Environment id (for your lookup): 9e112e9c-0d9f-4927-b3ad-9f538da1dbbe
Example failed build: bld-20260921-caf49683-bec0-4f5c-b3d4-c1cb5d1b02ba

Steps to Reproduce

Use a team environment linked to a repo with .cursor/environment.json that sets egressMode to default_with_network_settings and a non-empty egressAllowlist with at least one host not in Cursor’s built-in default list.

In the environment settings, choose Defaults + Environment Allowlist (UI network allowlist can stay empty if you rely on the repo file).

Start a new Cloud Agent or trigger an environment build from that environment.

On the VM, compare:

Config: environmentJson includes egressAllowlist.
Runtime: effective allowed domains / egress policy does not include those entries.
From the same VM, curl a known-default host (works) vs a host listed only in repo egressAllowlist (fails).

Operating System

MacOS

Version Information

Version: 3.21.16 (Universal)
VS Code Extension API: 1.128.0
Commit: 8ae78e8eee1e63479c7e0504b664bc0a80c68000
Date: 2026-09-19T06:43:22.276Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

Does this stop you from using Cursor

Yes - Cursor is unusable

6

Hey @fredrikk, thanks for the detailed report. This is expected behavior: a network access mode saved in the dashboard (like “Defaults + Environment Allowlist”) takes precedence over the egressAllowlist/egressMode in your repo’s .cursor/environment.json, even when the dashboard allowlist is empty. Two ways to fix it:

  • Quickest (what was working before): keep “Defaults + Environment Allowlist”, click Destinations, add your hosts one per line, save, then trigger a new build.
  • Keep the repo file authoritative: switch the environment’s mode to “Inherit Team Settings” so the repo file governs, with egressMode: default_with_network_settings and your hosts in egressAllowlist, then trigger a new build.

More on the modes: Cloud Agent network access. Let me know if the next build can reach your hosts - if not, drop the new build id and I’ll dig back in.

7

Thanks! I went with the second option to keep the repo file authoritative and it worked.

I thought it’d take the union of the repo file and what was specified in the UI with the “Defaults + Environment allowlist” option selected in both places, and it wasn’t clear to me that picking “Inherit team settings” would make it respect the repo file in this case.