Abhinav c3e60849e5 inline hostname resolution for remote sandbox config (#19739) ...

# Why

Requirements support host-specific
`remote_sandbox_config.hostname_patterns`, but config loading previously
resolved and passed the system hostname through every config-loading
path even when no requirements layer used `remote_sandbox_config`. On
machines where hostname lookup is slow, startup and app-server config
reads paid for a feature that was not active.

We only need the hostname when a requirements layer actually declares
`remote_sandbox_config`, so this moves hostname resolution to the single
requirements merge point and keeps all other config callers unaware of
hostname matching.

# What

- Removed the eager `host_name` plumbing from
`load_config_layers_state`, `load_requirements_toml`, `ConfigBuilder`,
app-server `ConfigManager`, network proxy loading, and related call
sites.
- Resolve the hostname inside
`merge_requirements_with_remote_sandbox_config` only when the incoming
requirements contain `remote_sandbox_config`.

c3e60849e5 · 2026-04-27 03:18:57 +00:00

History

..

examples

Add remote thread config loader protos (#18892)

2026-04-23 10:06:05 -07:00

scripts

Add remote thread config loader protos (#18892)

2026-04-23 10:06:05 -07:00

src

inline hostname resolution for remote sandbox config (#19739)

2026-04-27 03:18:57 +00:00

BUILD.bazel

Extract codex-config from codex-core (#11389)

2026-02-11 10:02:49 -08:00

Cargo.toml

[codex] Move config loading into codex-config (#19487)

2026-04-26 15:10:53 -07:00