Skip to content

chore: refactor network permissions to use explicit domain and unix socket rule maps#15120

Merged
celia-oai merged 11 commits intomainfrom
dev/cc/refactor
Mar 27, 2026
Merged

chore: refactor network permissions to use explicit domain and unix socket rule maps#15120
celia-oai merged 11 commits intomainfrom
dev/cc/refactor

Conversation

@celia-oai
Copy link
Copy Markdown
Collaborator

@celia-oai celia-oai commented Mar 19, 2026

Summary

This PR replaces the legacy network allow/deny list model with explicit rule maps for domains and unix sockets across managed requirements, permissions profiles, the network proxy config, and the app server protocol.

Concretely, it:

  • introduces typed domain (allow / deny) and unix socket permission (allow / none) entries instead of separate allowed_domains, denied_domains, and allow_unix_sockets lists
  • updates config loading, managed requirements merging, and exec-policy overlays to read and upsert rule entries consistently
  • exposes the new shape through protocol/schema outputs, debug surfaces, and app-server config APIs
  • rejects the legacy list-based keys and updates docs/tests to reflect the new config format

Why

The previous representation split related network policy across multiple parallel lists, which made merging and overriding rules harder to reason about. Moving to explicit keyed permission maps gives us a single source of truth per host/socket entry, makes allow/deny precedence clearer, and gives protocol consumers access to the full rule state instead of derived projections only.

Backward Compatibility

Backward compatible

  • Managed requirements still accept the legacy experimental_network.allowed_domains, experimental_network.denied_domains, and experimental_network.allow_unix_sockets fields. They are normalized into the new canonical domains and unix_sockets maps internally.
  • App-server v2 still deserializes legacy allowedDomains, deniedDomains, and allowUnixSockets payloads, so older clients can continue reading managed network requirements.
  • App-server v2 responses still populate allowedDomains, deniedDomains, and allowUnixSockets as legacy compatibility views derived from the canonical maps.
  • managed_allowed_domains_only keeps the same behavior after normalization. Legacy managed allowlists still participate in the same enforcement path as canonical domains entries.

Not backward compatible

  • Permissions profiles under [permissions.<profile>.network] no longer accept the legacy list-based keys. Those configs must use the canonical [domains] and [unix_sockets] tables instead of allowed_domains, denied_domains, or allow_unix_sockets.
  • Managed experimental_network config cannot mix canonical and legacy forms in the same block. For example, domains cannot be combined with allowed_domains or denied_domains, and unix_sockets cannot be combined with allow_unix_sockets.
  • The canonical format can express explicit "none" entries for unix sockets, but those entries do not round-trip through the legacy compatibility fields because the legacy fields only represent allow/deny lists.

Testing

/target/debug/codex sandbox macos --log-denials /bin/zsh -c 'curl https://www.example.com' gives 200 with config

[permissions.workspace.network.domains]
"www.example.com" = "allow"

and fails when set to deny: curl: (56) CONNECT tunnel failed, response 403.

Also tested backward compatibility path by verifying that adding the following to /etc/codex/requirements.toml works:

[experimental_network]
allowed_domains = ["www.example.com"]
@celia-oai celia-oai force-pushed the dev/cc/refactor branch 12 times, most recently from 6b9473c to 69d6d08 Compare March 19, 2026 23:43
@celia-oai celia-oai changed the title changes Mar 19, 2026
@celia-oai celia-oai changed the title Refactor network permissions to use explicit domain and unix socket rule maps Mar 19, 2026
@celia-oai celia-oai force-pushed the dev/cc/refactor branch 4 times, most recently from df83550 to 21117a7 Compare March 20, 2026 00:30
@celia-oai celia-oai marked this pull request as ready for review March 20, 2026 00:30
@celia-oai celia-oai requested a review from bolinfest March 20, 2026 00:30
@celia-oai
Copy link
Copy Markdown
Collaborator Author

@codex review

Copy link
Copy Markdown
Contributor

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 21117a718a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@celia-oai celia-oai force-pushed the dev/cc/refactor branch 2 times, most recently from 4353e7b to 626b34b Compare March 20, 2026 01:36
@celia-oai
Copy link
Copy Markdown
Collaborator Author

@codex review

Copy link
Copy Markdown
Contributor

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 626b34b281

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@celia-oai celia-oai force-pushed the dev/cc/refactor branch 2 times, most recently from 79185b4 to 4c42cf4 Compare March 20, 2026 01:58
@celia-oai
Copy link
Copy Markdown
Collaborator Author

@codex review

@celia-oai celia-oai force-pushed the dev/cc/refactor branch 3 times, most recently from 96ecaca to d20e87c Compare March 26, 2026 21:31
@celia-oai
Copy link
Copy Markdown
Collaborator Author

@codex review

Copy link
Copy Markdown
Contributor

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 85d53815b1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@celia-oai
Copy link
Copy Markdown
Collaborator Author

@codex review

1 similar comment
@celia-oai
Copy link
Copy Markdown
Collaborator Author

@codex review

Copy link
Copy Markdown
Contributor

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 71c88f94f2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +311 to +337
fn legacy_domain_permissions_from_lists(
allowed_domains: Option<Vec<String>>,
denied_domains: Option<Vec<String>>,
) -> Option<NetworkDomainPermissionsToml> {
let mut entries = BTreeMap::new();

for pattern in allowed_domains.unwrap_or_default() {
entries.insert(pattern, NetworkDomainPermissionToml::Allow);
}

for pattern in denied_domains.unwrap_or_default() {
entries.insert(pattern, NetworkDomainPermissionToml::Deny);
}

(!entries.is_empty()).then_some(NetworkDomainPermissionsToml { entries })
}

fn legacy_unix_socket_permissions_from_list(
allow_unix_sockets: Option<Vec<String>>,
) -> Option<NetworkUnixSocketPermissionsToml> {
let entries = allow_unix_sockets
.unwrap_or_default()
.into_iter()
.map(|path| (path, NetworkUnixSocketPermissionToml::Allow))
.collect::<BTreeMap<_, _>>();

(!entries.is_empty()).then_some(NetworkUnixSocketPermissionsToml { entries })
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Preserve explicit empty legacy network lists

These helpers collapse explicit legacy allowed_domains = [] / allow_unix_sockets = [] to None, which is not equivalent to the old structs. In danger-full-access, allowed_domains = [] used to clear and pin the allowlist to empty, but now it is treated as absent and leaves user allowlist entries intact. Likewise, allow_unix_sockets = [] used to keep dangerously_allow_all_unix_sockets constrained off via constraints.allow_unix_sockets = Some([]), but that constraint now disappears.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is unfortunately some lossiness expected after migrating to the new schema. I added a docstring here to explain this: https://github.com/openai/codex/pull/15120/changes#diff-6dea1db0d0ce5a6f3b19ccbc66cb916ad15d3bbc8ce347cff9a934445f9ce56eR311-R313

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel the better thing to do here is to get rid of dangerously_allow_all_unix_sockets down the road, and restrict danger-full-access behavior?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let me take a stab at seeing if we can preserve the behavior

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can land this though and we can do a fast follow

@celia-oai celia-oai enabled auto-merge (squash) March 27, 2026 05:52
@celia-oai celia-oai merged commit dd30c8e into main Mar 27, 2026
36 checks passed
@celia-oai celia-oai deleted the dev/cc/refactor branch March 27, 2026 06:18
@github-actions github-actions bot locked and limited conversation to collaborators Mar 27, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

2 participants