`Prepare Codex config for threat-detect` points Codex at the Anthropic api-proxy port (10001), breaks detection

[davidslater]

Summary

The .lock.yml step Prepare Codex config for threat-detect writes a Codex config.toml whose base_url / api_base / wss_base all point at http://172.30.0.30:10001. That port is the Anthropic ingress of the AWF api-proxy sidecar; the OpenAI ingress is 10000. As a result every Codex request in the detection job is rejected with 403 Forbidden: Credentials for Anthropic (port 10001) are not configured. Set ANTHROPIC_API_KEY to enable this provider., the engine exits without producing a verdict, and conclude_threat_detection.sh fails with ERR_SYSTEM: Detection result file not found.

The step's own leading comment reads # Point Codex at the AWF OpenAI proxy and disable websocket startup. — the intent is clearly the OpenAI port; this looks like a one-character typo (10001 → 10000) in the generator.

Impact

• All Codex-engine detection jobs run under AWF fail 100% of the time. They never invoke the AI backend at all.
• Reproduced today on github/gh-aw-threat-detection smoke-codex-standalone.lock.yml — see run 33095777489, job 98601015707.
• Copilot / Claude smokes are unaffected (they don't emit this config.toml).
• Because threat-detect correctly surfaces this as an engine/tooling failure (exit 2, no detection_result.json), the downstream safe-outputs job is blocked. So the failure is loud, but for the wrong reason — it looks like an infrastructure/credentials problem to anyone reading the job log.

Evidence

The offending step (from smoke-codex-standalone.lock.yml, detection job, step 17 "Prepare Codex config for threat-detect")

# Point Codex at the AWF OpenAI proxy and disable websocket startup.
cat > "${RUNNER_TEMP}/gh-aw/mcp-config/config.toml" << 'EOF'
model_provider = "openai-proxy"

[history]
persistence = "none"

[model_providers.openai-proxy]
name = "OpenAI AWF proxy"
base_url = "http://172.30.0.30:10001"   # ← should be :10000
api_base = "http://172.30.0.30:10001"   # ← should be :10000
wss_base = "ws://172.30.0.30:10001"     # ← should be :10000
env_key = "CODEX_API_KEY"
wire_api = "responses"
requires_openai_auth = false
supports_websockets = false
EOF

AWF api-proxy port map (for reference)

Port	Provider
10000	OpenAI
10001	Anthropic
10002	Copilot
10003	Gemini
10004	OpenCode

Runtime failure (excerpt from the detection job log)

[health-check] Testing connectivity to OpenAI API proxy at http://172.30.0.30:10000...
[health-check] ✓ OpenAI API proxy is reachable at http://172.30.0.30:10000
...
[threat-detect] engine invoke: engine=codex model="gpt-5.4-mini" ...
[engine] [codex-harness] awf-reflect: fetching http://api-proxy:10000/reflect
...
[engine] WARN codex_core::responses_retry: stream disconnected - retrying sampling request (1/5 …)
  sampling_error=unexpected status 403 Forbidden:
  Credentials for Anthropic (port 10001) are not configured.
  Set ANTHROPIC_API_KEY to enable this provider.,
  url: http://172.30.0.30:10001/responses
...
[threat-detect] attempt 1 outcome=engine_error err=node exited with code 1
THREAT_DETECTION_STATUS: reason=engine_error exit=2

The api-proxy sidecar itself is healthy on 10000 (health-check passed) and CODEX_API_KEY + OPENAI_API_KEY are both injected into the container. The reflect probe also correctly hits 10000. The only thing routing traffic to 10001 is the pinned base_url in CODEX_HOME/config.toml.

Why the agent job succeeds but detection fails

The agent job's Execute Codex CLI step does not write a config.toml that pins base_url. It lets the codex-harness use the endpoint returned by awf-reflect (10000), so requests land on the OpenAI ingress where OPENAI_API_KEY is valid.

The detection job is the only place this typo'd config.toml gets emitted, so it's the only Codex path that breaks. The AWF invocation flags themselves differ cosmetically between the two jobs (allowDomains list, topologyAttach, DIFC proxy flags, exclude-env list) but none of those affect api-proxy routing.

Suggested fix

In whatever template renders the Prepare Codex config for threat-detect step, change all three URLs from 172.30.0.30:10001 to 172.30.0.30:10000:

 [model_providers.openai-proxy]
 name = "OpenAI AWF proxy"
-base_url = "http://172.30.0.30:10001"
-api_base = "http://172.30.0.30:10001"
-wss_base = "ws://172.30.0.30:10001"
+base_url = "http://172.30.0.30:10000"
+api_base = "http://172.30.0.30:10000"
+wss_base = "ws://172.30.0.30:10000"
 env_key = "CODEX_API_KEY"
 wire_api = "responses"

If the ports come from a shared constant, please double-check the name — the current value looks like Anthropic's port was mistakenly used for the "openai-proxy" provider.

Test coverage suggestion

A cheap regression guard: after generating the Codex detection config.toml, grep -q '172\.30\.0\.30:10000' config.toml in a unit or lock-compilation test, or assert that model_providers.openai-proxy.base_url ends in :10000.

Repro

1. In a repo consuming gh-aw, compile any engine: codex workflow that emits a threat-detection job (e.g. this repo's smoke-codex-standalone.md).
2. Run it against real credentials (OPENAI_API_KEY / CODEX_API_KEY set, no ANTHROPIC_API_KEY).
3. The detection job fails at Conclude threat detection with ERR_SYSTEM: Detection result file not found. Upstream in Execute threat detection with AWF you'll see the 403 Forbidden … port 10001 retries.

References

• Failing run: https://github.com/github/gh-aw-threat-detection/actions/runs/33095777489/job/98601015707
• AWF port map: github/gh-aw-threat-detection → CLAUDE.md → "API Proxy Sidecar" section
• Detector contract (why no fallback verdict is produced when the engine can't call the tool): github/gh-aw-threat-detection → specs/threat-detection-spec.md