## Why
Sandbox invocations without an explicit permissions profile and remote `exec-server` connections using ChatGPT auth need access to cloud-defined model providers and managed requirements. Cloud bootstrap requests must also respect local application network policy.
## What changed
- Bootstrap sandbox cloud config whenever managed config is included, even without an explicit profile. Skip bootstrap when `--sandbox-state-json` supplies the sandbox state.
- Load cloud config for remote executors beyond workload identity, while skipping forwarders and executors using stdin credentials, AWS SigV4, or agent identity auth. Honor `CODEX_API_KEY` selection so API key connections skip ChatGPT cloud config.
- Apply local application network policy during cloud bootstrap and activate effective application network policy before exec-server clients are created.
## Testing
Add coverage for cloud-defined providers in sandbox and remote exec-server invocations, API key bypass, local policy blocking bundle requests, cloud policy blocking remote registration, and bootstrap exclusions.
GitOrigin-RevId: e8bd6210751e96161f575ade309ebf41bf10f8b5
## What changed
- Rename ChatGPT-specific bundle loaders to `chatgpt_config_bundle_loader*` and use managed-config terminology for shared loader plumbing.
- Pass `Config` directly when updating the app-server's managed configuration loader.
- Share configuration loading, logging setup, and result handling between browser and device-code login.
- Expose the CLI cloud-config helpers and `provider_uses_first_party_auth_path` through their library APIs.
## Testing
Extend CLI login coverage to verify that `forced_login_method="api"` rejects both `login` and `login --device-auth` while preserving saved API-key credentials.
GitOrigin-RevId: 9e8fa6110dc80882ba365e550b48ac77da604940
## What changed
- Treat workload identity environment markers as an explicit authentication selection, even when another process credential is present.
- Return initialization errors from `AuthManager` and propagate them through commands and services instead of continuing with an unusable authentication state.
- Make `codex login status` validate workload identity, keep the TUI on an embedded app server for local workload identity, and reject workload identity in `codex mcp-server`, where it is unsupported.
## Testing
- Cover workload identity precedence and partial configuration errors.
- Verify login status reports an unreadable identity assertion and app-server routing enforces the supported workload identity topology.
GitOrigin-RevId: efc6b6b4cd4d61652617de82aaa3d7ffc75d6618
## Why
Authentication restrictions must apply before stored or environment-provided credentials can be used, including during bootstrap before cloud requirements are fetched.
## What changed
- Add local `requirements.toml` allowlists for login methods and ChatGPT workspaces. Ignore these fields in cloud-provided requirements.
- Combine managed workspace allowlists with existing workspace restrictions by intersection, and fail closed when the resulting policy permits no usable login method.
- Centralize policy checks in the authentication manager so CLI, TUI, app-server, external-auth, and credential-loading paths consistently reject disallowed authentication before token hydration or network requests.
## Testing
- Cover policy composition, workspace intersection, invalid stored and external credentials, bootstrap enforcement, and login endpoint restrictions.
GitOrigin-RevId: efef22b248f3c3333e9aa55423e539efa2d2dd48
## What changed
- Bootstrap the cloud configuration bundle when `codex sandbox` receives an
explicit permission profile together with `--include-managed-config`.
- Pass the resulting managed requirements through sandbox configuration loading
so the requested cloud-managed permission profile is enforced.
- Keep the default path from loading cloud-managed profiles when managed
configuration is not requested.
## Testing
- Add unit and subprocess coverage for fetching, caching, and enforcing a
cloud-managed permission profile.
GitOrigin-RevId: dfe637af5895496ae88b8128ca2f5ec29341ad06
This adds a debugging tool for analyzing why certain commands fail to
execute under the sandbox.
Example output:
```
$ codex debug seatbelt --log-denials bash -lc "(echo foo > ~/foo.txt)"
bash: /Users/nornagon/foo.txt: Operation not permitted
=== Sandbox denials ===
(bash) file-write-data /dev/tty
(bash) file-write-data /dev/ttys001
(bash) sysctl-read kern.ngroups
(bash) file-write-create /Users/nornagon/foo.txt
```
It operates by:
1. spawning `log stream` to watch system logs, and
2. tracking all descendant PIDs using kqueue + proc_listchildpids.
this is a "best-effort" technique, as `log stream` may drop logs(?), and
kqueue + proc_listchildpids isn't atomic and can end up missing very
short-lived processes. But it works well enough in my testing to be
useful :)
Abhinav