[awf] agent-container: Gemini CLI ENOENT on project registry due to ~/.gemini ownership in chroot

[lpcox]

Problem

When the Gemini CLI runs inside the AWF agent container, it fails at startup with an ENOENT error while attempting to rename its project registry file:

Failed to save project registry: Error: ENOENT: no such file or directory,
rename '.../projects.json.tmp' -> '.../projects.json'
```

This is followed by authentication failure (exit code 41) because the CLI cannot initialize its state directory. The error occurs even when the agent container's `~/.gemini` volume is mounted.

This is related to but distinct from the Gemini API proxy issue tracked in github/gh-aw#25294: that issue covers the missing proxy handler; this issue covers the Gemini CLI's inability to initialize its project registry within the AWF chroot/mount environment.

## Context

Original `github/gh-aw` issue: https://github.com/github/gh-aw/issues/23655

Observed log sequence:
```
[WARN] API proxy enabled but no API keys found in environment
Failed to save project registry: Error: ENOENT: no such file or directory,
  rename '.../projects.json.tmp' -> '.../projects.json'
Please set an Auth method ... GEMINI_API_KEY, GOOGLE_GENAI_USE_VERTEXAI, ...
[WARN] Command completed with exit code: 41
```

## Root Cause

Two layered issues:

**1. Project registry ENOENT (primary)**

The Gemini CLI writes its project registry to `~/.gemini/` using atomic rename (`tmp` → final). In `src/docker-manager.ts` (~line 969), AWF mounts the host's `~/.gemini` into the agent container:
```
\$\{effectiveHome}/.gemini:/host\$\{effectiveHome}/.gemini:rw

However, if ~/.gemini/ does not exist on the host at the time the container starts, Docker creates it as root-owned, and the agent (running as the host user UID/GID after entrypoint.sh remaps) cannot write to it. The rename of a .tmp file to its final name fails with ENOENT because the parent directory is inaccessible.

2. API proxy / auth fallback

When --enable-api-proxy is active but GEMINI_API_KEY is not set in the runner environment, the API proxy starts its Gemini listener in 503 fallback mode. The Gemini CLI then has no valid authentication method.

Proposed Solution

Fix 1 (ENOENT): In containers/agent/entrypoint.sh, before dropping capabilities and executing the user command, ensure the ~/.gemini directory exists and is owned by the agent user:

# Ensure Gemini CLI state directory exists with correct ownership
mkdir -p "/host\$\{HOME}/.gemini"
chown "\$\{TARGET_UID}:\$\{TARGET_GID}" "/host\$\{HOME}/.gemini"

Alternatively, create and chown the directory in src/docker-manager.ts (host-side, before the container starts) — similar to how agentLogsPath and sessionStatePath are created at ~line 247.

Fix 2 (auth warning): In src/docker-manager.ts, when --enable-api-proxy is active but geminiApiKey is not set, emit a visible [WARN] that the Gemini CLI will not be able to authenticate (currently only the API proxy itself logs this, which is not surfaced to the user).

Generated by Firewall Issue Dispatcher · ● 1.4M · ◷