Skip to content

exec-server: start managed network proxy on executor - #31453

Open
viyatb-oai wants to merge 4 commits into
mainfrom
codex/viyatb/remote-exec-network-proxy
Open

exec-server: start managed network proxy on executor#31453
viyatb-oai wants to merge 4 commits into
mainfrom
codex/viyatb/remote-exec-network-proxy

Conversation

@viyatb-oai

@viyatb-oai viyatb-oai commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Summary

  • send a sanitized effective managed-network policy to remote exec-server processes
  • start and own HTTP/SOCKS proxy listeners on the executor, then derive child env and sandbox ports locally
  • fail closed for MITM, credential injection, and hook configuration until that boundary is implemented

Why

Core currently prepares orchestrator-local loopback endpoints for remote commands. The remote sandbox receives those ports, but exec-server never creates a reachable proxy on the executor, so managed networking fails closed without usable egress.

Stack follow-up: preserve inline Guardian network decisions across the exec-server transport.

Co-authored-by: Codex noreply@openai.com
Co-authored-by: Codex noreply@openai.com
else {
return Ok((env, managed_network.cloned(), None));
};
let state = NetworkProxyState::from_static_config(proxy_config.into_network_proxy_config())

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This freezes managed-network policy for the whole remote process lifetime. Core updates the shared local proxy when the permission profile or domain policy changes, but an existing executor proxy keeps its launch-time access. We need an update path or a session-scoped proxy whose policy remains Core-owned

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

[from Codex]: Agreed this needs an explicit update/reload boundary. Reload is intentionally out of scope for this stack, so I have not resolved this thread. The Guardian follow-up keeps Core-owned decisions for policy misses, but it does not claim to update already-materialized static executor policy.

Comment thread codex-rs/core/src/tools/runtimes/unified_exec.rs Outdated
Comment thread codex-rs/network-proxy/src/runtime.rs
Co-authored-by: Codex noreply@openai.com
Co-authored-by: Codex noreply@openai.com
@viyatb-oai
viyatb-oai marked this pull request as ready for review July 9, 2026 17:45
@viyatb-oai
viyatb-oai requested a review from a team as a code owner July 9, 2026 17:45
Some(ProcessEntry::Starting(_)) | None => (false, None),
}
};
if let Some(network_proxy_handle) = network_proxy_handle

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This ties the proxy lifetime to the direct child, but exec-server explicitly allows descendants to outlive it
Background commands inherit these proxy URLs, so leader exit removes their only sandbox-permitted egress while they’re still running. Is this expected?


impl NetworkProxyState {
/// Builds immutable runtime state from an already-computed effective configuration.
pub fn from_static_config(config: NetworkProxyConfig) -> Result<Self> {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can we remove this for now? I don't see callers after the launch config split

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants