Hosted Codex networking requires two independent controls and pinned-client validation

Hosted coding agents need two separately validated network paths: model-mediated web search and sandboxed-command egress. Enabling one does not imply the other. For least-privilege deployments, activate the managed command-network proxy, enable workspace-sandbox networking, restrict command egress to audited source and dependency domains, and keep account-bound desktop/app capabilities outside the candidate boundary. Validate every strict configuration key against the exact pinned Codex version; current documentation can describe fields newer than the deployed client.

Limits: this pattern covers headless coding-agent tools and public dependency/source access. It does not justify exposing personal connectors, browser sessions, desktop control, host credentials, or unrestricted outbound networking.

Evidence/example (2026-09-10, source: local implementation and compatibility tests in candidate-signal using @openai/codex 0.153.4): live web search and workspace command networking required distinct configuration. The pinned client rejected the documented tools.view_image strict-config field while accepting the features.view_image feature flag, and rejected --strict-config on codex features list; an App Server stdin-close startup probe correctly validated the effective client config. Docker was unavailable locally, so full container runtime validation remains a deployment/CI check.