Summary
When the codex engine is pointed at a custom OpenAI-compatible endpoint via engine.env.OPENAI_BASE_URL, the main agent job works, but the threat-detection job always fails (agentic execution exit 1) and every safe-output comment gets the agentic threat detected / results could not be parsed caution banner.
Environment
- gh-aw v0.81.6, AWF containers 0.27.11
engine: {id: codex, env: {OPENAI_BASE_URL: "https://<internal-router>/v1", OPENAI_API_KEY: ...}}
- self-hosted Linux runner, firewall rootless (
sandbox.agent.sudo: false)
safe-outputs: {add-comment: {max: 1}}
Symptom
Detection job log: codex fails with repeated models fetch returned 503 for http://api-proxy:10000/v1/models, then DETECTION_AGENTIC_EXECUTION_OUTCOME: failure. Main agent job in the same run succeeds against the same endpoint.
Root cause (from source)
- The AWF api-proxy
targets.openai.host is derived only from WorkflowData.EngineConfig.Env["OPENAI_BASE_URL"] — pkg/workflow/awf_config.go:507 (extractAPITargetHost).
- The detection job rebuilds its WorkflowData with
EngineConfig{ID, APITarget} and does not inherit Env — pkg/workflow/threat_detection_external.go (threatDetectionData.EngineConfig = &EngineConfig{ID: engineID} / the canReuseThreatDetectionEngineConfigForExternalDetector branch copies APITarget only).
- Result: the detection api-proxy has no custom openai target, dials the default host with a key that is only valid on the custom router → every request fails → 503 to codex.
Related secondary issue: getThreatDetectionAdditionalAllowedDomains (pkg/workflow/threat_detection_helpers.go:73) propagates custom network.allowed entries to the detection firewall only when COPILOT_PROVIDER_BASE_URL is set, so codex+custom-endpoint users lose their squid allowlist entries in detection too. Setting engine.api-target works around the allowlist half (via mergeAPITargetDomains) but not the api-proxy target half.
Expected
Detection should reach the same endpoint the main engine uses: inherit the engine base-URL env vars (OPENAI_BASE_URL, ANTHROPIC_BASE_URL) into the detection EngineConfig.Env, or compute the detection awf-config apiProxy targets from the parent WorkflowData.
Workaround
safe-outputs: {threat-detection: false} — which drops the detection layer entirely for custom-endpoint users.
Summary
When the codex engine is pointed at a custom OpenAI-compatible endpoint via
engine.env.OPENAI_BASE_URL, the main agent job works, but the threat-detection job always fails (agentic execution exit 1) and every safe-output comment gets theagentic threat detected / results could not be parsedcaution banner.Environment
engine: {id: codex, env: {OPENAI_BASE_URL: "https://<internal-router>/v1", OPENAI_API_KEY: ...}}sandbox.agent.sudo: false)safe-outputs: {add-comment: {max: 1}}Symptom
Detection job log: codex fails with repeated
models fetch returned 503 for http://api-proxy:10000/v1/models, thenDETECTION_AGENTIC_EXECUTION_OUTCOME: failure. Main agent job in the same run succeeds against the same endpoint.Root cause (from source)
targets.openai.hostis derived only fromWorkflowData.EngineConfig.Env["OPENAI_BASE_URL"]—pkg/workflow/awf_config.go:507(extractAPITargetHost).EngineConfig{ID, APITarget}and does not inheritEnv—pkg/workflow/threat_detection_external.go(threatDetectionData.EngineConfig = &EngineConfig{ID: engineID}/ thecanReuseThreatDetectionEngineConfigForExternalDetectorbranch copiesAPITargetonly).Related secondary issue:
getThreatDetectionAdditionalAllowedDomains(pkg/workflow/threat_detection_helpers.go:73) propagates customnetwork.allowedentries to the detection firewall only whenCOPILOT_PROVIDER_BASE_URLis set, so codex+custom-endpoint users lose their squid allowlist entries in detection too. Settingengine.api-targetworks around the allowlist half (viamergeAPITargetDomains) but not the api-proxy target half.Expected
Detection should reach the same endpoint the main engine uses: inherit the engine base-URL env vars (
OPENAI_BASE_URL,ANTHROPIC_BASE_URL) into the detectionEngineConfig.Env, or compute the detection awf-config apiProxy targets from the parent WorkflowData.Workaround
safe-outputs: {threat-detection: false}— which drops the detection layer entirely for custom-endpoint users.