[awf] API Proxy: codex engine fails with 401 Unauthorized on OpenAI API

[lpcox]

Problem

The codex engine in the AI Moderator workflow repeatedly fails with 401 Unauthorized when attempting to reach `(api.openai.com/redacted) The engine retries 5 times and then terminates without producing output. This is a persistent failure affecting multiple runs (at least 6 consecutive runs as of 2026-04-18).

Error pattern:

unexpected status 401 Unauthorized: Missing bearer or basic authentication in header
url: (api.openai.com/redacted)

Context

• Original issue: [aw] AI Moderator failed gh-aw#26911
• Failed workflow runs: 24575674483, 24576029347, 24577634319, 24579500430, 24579781734, 24589368675, 24590101486

The AWF API proxy sidecar (containers/api-proxy/) is designed to inject real API credentials (OpenAI on port 10000) so the agent never sees them directly. When --enable-api-proxy is active, the agent should send unauthenticated requests to `(172.30.0.30/redacted) and the sidecar injects the real OpenAI key before forwarding through Squid.

The /v1/responses endpoint is a newer OpenAI endpoint (used by the codex CLI) that may not be covered by the proxy routing rules. The codex engine appears to be calling api.openai.com/v1/responses directly with no auth header, suggesting either:

1. The API proxy sidecar is not routing /v1/responses requests (only /v1/chat/completions or similar older paths), or
2. The codex engine is not configured to use `(172.30.0.30/redacted) as its base URL, or
3. The OpenAI API key secret used by the sidecar is expired/invalid/missing.

Root Cause

Most likely one of:

1. Missing env var / secret: The OPENAI_API_KEY secret used by the API proxy sidecar is not set or has expired in the gh-aw repository secrets, so the sidecar forwards requests with no Authorization header.
2. Endpoint not proxied: The sidecar (containers/api-proxy/) handles specific OpenAI paths but does not forward the /v1/responses endpoint used by newer codex CLI versions. Check containers/api-proxy/ handler logic.
3. codex not using proxy: The codex engine may not honor HTTP_PROXY/HTTPS_PROXY env vars or the OPENAI_BASE_URL override pointing to the sidecar.

Proposed Solution

1. Verify the secret: Check that OPENAI_API_KEY (or equivalent) is configured in the gh-aw repository secrets and has not expired.

2. Audit the API proxy handler (containers/api-proxy/): Ensure the proxy transparently forwards ALL paths under api.openai.com (not just specific endpoints), so /v1/responses is covered alongside /v1/chat/completions.

3. Configure codex base URL: If the codex engine supports OPENAI_BASE_URL, set it to (172.30.0.30/redacted) in the workflow environment so requests go through the sidecar rather than directly to api.openai.com`.

4. Add /v1/responses to allowed domains: Ensure api.openai.com is in the Squid domain allowlist for workflows using the codex engine.

5. Add a health-check or startup validation in the API proxy sidecar that verifies the injected key is non-empty before accepting connections, so misconfiguration fails fast rather than silently forwarding unauthenticated requests.

Generated by Firewall Issue Dispatcher · ● 194.9K · ◷