Summary

When OpenClaw is configured with a Google/Gemini provider API key and the gateway is installed as a systemd user service via openclaw gateway install, the generated ~/.config/systemd/user/openclaw-gateway.service contains the key as a literal Environment=GEMINI_API_KEY=*** line. It is not a ${VAR}` reference and is not managed via the runtime injection pattern.

Every other provider secret in the same file (OpenAI, xAI, Discord tokens, Slack tokens, Brave, GBrain database URL) is handled via OPENCLAW_SERVICE_MANAGED_ENV_KEYS and resolved at runtime. GEMINI_API_KEY was not added to this list. It is the only hardcoded secret value in a service file otherwise handled correctly.

Reproduction steps

1. Configure OpenClaw with a Google/Gemini provider API key.
2. Run openclaw gateway install to generate the systemd user service.
3. Read ~/.config/systemd/user/openclaw-gateway.service.
4. Observe: Environment=GEMINI_API_KEY=<plain…ue>
5. Compare: all other secrets appear in Environment=OPENCLAW_SERVICE_MANAGED_ENV_KEYS=...

Expected behavior

GEMINI_API_KEY is included in OPENCLAW_SERVICE_MANAGED_ENV_KEYS alongside OpenAI, xAI, Discord, and all other provider secrets. No plaintext API key values appear in the service file.

Actual behavior

GEMINI_API_KEY is the sole hardcoded secret value in the service file. The managed-env runtime injection pattern that handles all other providers was not applied to the Google Gemini key. This exposes the key in systemctl show, process environment dumps, crash reporters, and any tool that reads service definitions.

Proposed fix

Add GEMINI_API_KEY to the OPENCLAW_SERVICE_MANAGED_ENV_KEYS list in the gateway install path, consistent with how all other provider API keys are handled.

Context

• OpenClaw: 2026.6.9
• OS: Linux (WSL2, Ubuntu)
• Service file path: ~/.config/systemd/user/openclaw-gateway.service
• Distinct from the SecretRef configuration path; this is an install-time file-write issue.
• Key value rotated; not included in this report.