Problem
Codex workflows cannot configure a custom OpenAI-compatible API proxy target from a runtime secret. The OpenAI target is currently static, so a sensitive endpoint host must be embedded in generated configuration or injected by brittle post-compilation lockfile patching.
Context
Original issue: github/gh-aw#41929
Users may route engine: codex through a private OpenAI-compatible load balancer whose URL and hostname are sensitive. The endpoint must not appear in committed workflow source, generated lockfiles, logs, diagnostics, uploaded artifacts, or the sandboxed agent environment.
Current behavior
The API proxy reads its OpenAI target as a concrete startup value. AWF has no baseUrlEnv-style configuration that:
- resolves a URL from runner environment at runtime;
- validates and normalizes it before containers start;
- derives the destination host for network policy;
- keeps the value out of the agent environment; and
- registers the URL, host, and host:port for masking and artifact redaction.
Copilot BYOK configuration is not equivalent because this request applies specifically to the Codex/OpenAI API-proxy path.
Proposed solution
Add an AWF configuration field for an environment-backed OpenAI target, for example:
{
"apiProxy": {
"targets": {
"openai": {
"baseUrlEnv": "CODEX_LB_BASE_URL"
}
}
}
}At startup, AWF should:
- Read the named variable only in runner-side configuration code.
- Require an HTTP(S) URL and reject embedded credentials, malformed hosts, and unsupported schemes.
- Derive the host, host:port, and optional base path.
- Add the derived destination to the effective Squid/network policy without persisting it in repository configuration.
- Configure the OpenAI API-proxy adapter with the resolved target.
- Ensure the secret is excluded from the primary agent environment.
- Mask and redact the full URL, host, and host:port from logs, diagnostics, and uploaded artifacts.
- Apply the behavior consistently to agent and detection phases.
The gh-aw compiler can then bind ${{ secrets.CODEX_LB_BASE_URL }} to the named runner environment variable without writing its value into the lockfile.
Acceptance criteria
- A Codex workflow can route through a secret-backed OpenAI-compatible endpoint without post-processing its generated lockfile.
- The endpoint value and derived host forms do not appear in committed/generated workflow configuration, agent environment, logs, diagnostics, or artifacts.
- Runtime network policy permits only the validated derived endpoint.
- Invalid or missing values fail before agent startup with a clear, redacted error.
- Tests cover URL validation, network-policy derivation, credential isolation, and redaction.
Problem
Codex workflows cannot configure a custom OpenAI-compatible API proxy target from a runtime secret. The OpenAI target is currently static, so a sensitive endpoint host must be embedded in generated configuration or injected by brittle post-compilation lockfile patching.
Context
Original issue: github/gh-aw#41929
Users may route
engine: codexthrough a private OpenAI-compatible load balancer whose URL and hostname are sensitive. The endpoint must not appear in committed workflow source, generated lockfiles, logs, diagnostics, uploaded artifacts, or the sandboxed agent environment.Current behavior
The API proxy reads its OpenAI target as a concrete startup value. AWF has no
baseUrlEnv-style configuration that:Copilot BYOK configuration is not equivalent because this request applies specifically to the Codex/OpenAI API-proxy path.
Proposed solution
Add an AWF configuration field for an environment-backed OpenAI target, for example:
{ "apiProxy": { "targets": { "openai": { "baseUrlEnv": "CODEX_LB_BASE_URL" } } } }At startup, AWF should:
The
gh-awcompiler can then bind${{ secrets.CODEX_LB_BASE_URL }}to the named runner environment variable without writing its value into the lockfile.Acceptance criteria