[awf] api-proxy: Gemini engine fails when GEMINI_API_KEY not forwarded to api-proxy sidecar

[lpcox]

Problem

When a workflow uses engine: gemini and the --enable-api-proxy flag is active, the Gemini CLI fails at startup with exit code 41:

Please set an Auth method in your /home/runner/.gemini/settings.json or specify
one of the following environment variables before running: GEMINI_API_KEY,
GOOGLE_GENAI_USE_VERTEXAI, GOOGLE_GENAI_USE_GCA
```

This happens even though `GEMINI_API_KEY` is set as a GitHub Actions secret and visible (as `***`) in the runner logs. The api-proxy sidecar starts but reports no Gemini key:

```
[INFO] API proxy enabled: OpenAI=false, Anthropic=false, Copilot=false
[WARN] ⚠️  API proxy enabled but no API keys found in environment

The Gemini CLI receives GEMINI_API_BASE_URL pointing to the api-proxy sidecar (port 10003), and a placeholder GEMINI_API_KEY is injected by AWF so the Gemini CLI's startup auth check passes — but the proxy itself has no real key and cannot authenticate upstream requests.

Context

Original report: github/gh-aw#25294

Root Cause

In src/docker-manager.ts, GEMINI_API_KEY is forwarded to the api-proxy sidecar only when config.geminiApiKey is set (line 1484). config.geminiApiKey is populated from process.env.GEMINI_API_KEY in src/cli.ts (line 1824).

The likely failure mode is that GEMINI_API_KEY is not present in process.env when the AWF CLI is invoked — i.e. the gh-aw compiler's generated step does not expose the secret to the AWF process. As a result:

• config.geminiApiKey is undefined
• GEMINI_API_KEY is not passed to the api-proxy environment (docker-manager.ts:1484)
• The api-proxy never starts its Gemini listener on port 10003 (server.js:889)
• GEMINI_API_BASE_URL is not set in the agent environment, because the block at docker-manager.ts:1601 is guarded by config.geminiApiKey

However, the reporter observes GEMINI_API_BASE_URL IS set (pointing to host.docker.internal:10003), which suggests either the gh-aw compiler injects this variable independently or an older AWF version handled things differently.

Secondary possibility: when using an older GHCR image of the api-proxy (pulled with --image-tag), Gemini support may not have been present in that version.

Proposed Solution

1. Defensive check in src/docker-manager.ts: If --enable-api-proxy is active but config.geminiApiKey is absent, and the agent command references Gemini (e.g. GEMINI_API_BASE_URL already set via --env), emit a clear warning:

   [WARN] --enable-api-proxy is active but GEMINI_API_KEY is not set.
          The api-proxy Gemini listener (port 10003) will not start.
          Set GEMINI_API_KEY in the AWF runner environment to enable credential isolation.
   

2. api-proxy hardening (containers/api-proxy/server.js): When GEMINI_API_BASE_URL is set in the agent environment but no GEMINI_API_KEY is present in the sidecar, the proxy should return HTTP 503 with a descriptive message rather than silently refusing connections, so the failure message surfaced to the user is actionable.

3. Compiler-side fix: Ensure the gh-aw compiler forwards GEMINI_API_KEY from GitHub Actions secrets to the AWF CLI invocation environment so process.env.GEMINI_API_KEY is populated when engine: gemini is compiled with --enable-api-proxy.

Generated by Firewall Issue Dispatcher · ● 720.5K · ◷