Summary

• Mark Google/Gemini auth-profile env refs as systemd file-backed service env values.
• Preserve the current main config SecretRef behavior where GEMINI_API_KEY is managed through OPENCLAW_SERVICE_MANAGED_ENV_KEYS and delivered by the generated EnvironmentFile.
• Add a regression test covering the combined config SecretRef plus auth-profile path on Linux.

What Problem This Solves

Current main already keeps Google/Gemini config SecretRefs out of inline systemd unit assignments by treating those config keys as managed service env keys. The remaining gap is auth-profile env refs: Google/Gemini auth-profile keys still used the default inline service env value source, so the generated systemd unit could render plaintext Environment=GOOGLE_API_KEY=... or Environment=GEMINI_API_KEY=... assignments for those auth-profile credentials.

The fix marks known Google/Gemini auth-profile env-ref keys as environmentValueSources: "file". The existing systemd staging contract then writes those values to the generated owner-only EnvironmentFile and omits plaintext assignments from the unit file.

User Impact

Users who install the gateway as a systemd service with Google/Gemini credentials supplied through auth-profile env refs no longer get those keys embedded in the generated unit file. The service still receives the credentials at runtime via the generated EnvironmentFile.

• Why it matters / User impact: The generated unit is easier to inspect, back up, and diagnose without exposing Google/Gemini credential material in plaintext Environment= lines.

Origin / follow-up

Fixes #95895.

This is an existing PR updated after syncing with current main. The current main branch already covers the config SecretRef managed-key portion; this update keeps that behavior and narrows the remaining fix to Google/Gemini auth-profile env refs.

Competition / linked PR analysis

Linked PRs #95908, #96059, and #96065 also target #95895. After syncing with main, #96065's config SecretRef managed-key behavior is already present on the base branch.

• Linked PR(s): fix(config): collect GEMINI_API_KEY from system env into managed service keys #95908, fix(install): manage auth-profile env refs via OPENCLAW_SERVICE_MANAGED_ENV_KEYS #96059, fix(install): manage config-secretref env refs via OPENCLAW_SERVICE_MANAGED_ENV_KEYS #96065
• Gap in linked PR(s): Current main covers the config SecretRef managed-key path, but auth-profile Google/Gemini env refs still defaulted to inline service env rendering.
• Why this patch is better/canonical: This patch uses the existing environmentValueSources: "file" contract that systemd staging already owns for generated EnvironmentFile values, and applies it only to the remaining auth-profile Google/Gemini env-ref gap.
• Local real behavior proof advantage: The proof stages a real unit and generated 0600 EnvironmentFile with OpenClaw's production systemd staging code, then checks both absence of inline plaintext and presence of file-backed runtime values.
• Related open PR scan: linked issue scan found fix(config): collect GEMINI_API_KEY from system env into managed service keys #95908, fix(install): manage auth-profile env refs via OPENCLAW_SERVICE_MANAGED_ENV_KEYS #96059, and fix(install): manage config-secretref env refs via OPENCLAW_SERVICE_MANAGED_ENV_KEYS #96065; after the main sync, this PR is scoped to the auth-profile gap left outside the config SecretRef behavior now on main.

This PR keeps the current main config SecretRef result: GEMINI_API_KEY remains represented in OPENCLAW_SERVICE_MANAGED_ENV_KEYS and is still delivered by the generated EnvironmentFile. It adds the missing auth-profile value-source metadata so Google/Gemini auth-profile keys also go through the generated EnvironmentFile instead of inline unit Environment= values.

Real behavior proof

• Behavior or issue addressed: Google/Gemini env-ref secrets from auth profiles must not be written as plaintext Environment=GEMINI_API_KEY=... or Environment=GOOGLE_API_KEY=... entries in the generated systemd unit, while still being delivered to the service. The proof also verifies that current main's config SecretRef managed-key behavior remains intact.
• Real environment tested: Linux worktree using the production buildGatewayInstallPlan and stageSystemdService paths with a temporary HOME/state dir. A fake systemctl binary returned success for the local availability gate; OpenClaw's production systemd staging code produced the unit file and EnvironmentFile.
• Exact steps or command run after this patch:

cd /media/vdb/code/ai/aispace/openclaw-worktrees/pr-96149
PROOF_HEAD=$(git rev-parse HEAD) ./node_modules/.bin/tsx /media/vdb/code/ai/aispace/openclaw-issue-95895-evidence/gemini-managed-env-proof.mts
node scripts/run-vitest.mjs src/commands/daemon-install-helpers.test.ts
./node_modules/.bin/oxfmt --check src/commands/daemon-install-helpers.ts src/commands/daemon-install-helpers.test.ts
node scripts/run-oxlint.mjs --tsconfig config/tsconfig/oxlint.core.json src/commands/daemon-install-helpers.ts src/commands/daemon-install-helpers.test.ts
node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test-after-sync.tsbuildinfo
node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.extensions.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/extensions-test-after-sync.tsbuildinfo
git diff --check

• Evidence after fix:

HEAD=fe757649357653498548269ec709ccfa3e551656
managed=GEMINI_API_KEY
plan source GEMINI_API_KEY=file
plan source GOOGLE_API_KEY=file
unit contains proof-gemini-key=false
unit contains proof-google-key=false
unit has Environment=GEMINI_API_KEY=false
unit has Environment=GOOGLE_API_KEY=false
unit has generated EnvironmentFile=true
env file contains GEMINI_API_KEY=true
env file contains GOOGLE_API_KEY=true
env file mode=600
PASS: Gemini/Google env refs are delivered through the generated 0600 systemd EnvironmentFile, not inline unit Environment values.

Test Files  1 passed (1)
     Tests  49 passed (49)
[test] passed 1 Vitest shard in 52.57s

Checking formatting...

All matched files use the correct format.
Finished in 86ms on 2 files using 8 threads.

node scripts/run-oxlint.mjs --tsconfig config/tsconfig/oxlint.core.json src/commands/daemon-install-helpers.ts src/commands/daemon-install-helpers.test.ts
# exit 0, no diagnostics

node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test-after-sync.tsbuildinfo
# exit 0, no diagnostics
node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.extensions.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/extensions-test-after-sync.tsbuildinfo
# exit 0, no diagnostics

git diff --check
# exit 0, no whitespace errors

• Observed result after fix: The staged systemd unit has no inline Google/Gemini secret assignments or secret literals; the generated EnvironmentFile is referenced by the unit, contains both runtime service env values, and has mode 0600. The install plan keeps current main's OPENCLAW_SERVICE_MANAGED_ENV_KEYS=GEMINI_API_KEY result for the config SecretRef path, and marks both GEMINI_API_KEY and GOOGLE_API_KEY as file in environmentValueSources.
• What was not tested: Out of scope for this patch: restarting an already installed user service and calling the external Google/Gemini API. The tested boundary is the local systemd service staging/file-generation path that writes the unit and EnvironmentFile.
• Fix classification: Root cause fix

Merge risk

• Risk labels considered: security-boundary, auth-provider, public-config, compatibility
• Risk explanation: The changed contract surface is generated daemon service environment metadata for Google/Gemini auth-profile env-ref keys. The source of truth remains the install-plan environmentValueSources metadata that systemd staging already uses for file-backed service env values.
• Why acceptable: The diff only changes value-source selection for known Google/Gemini auth-profile env key names. Existing current-main behavior for config SecretRefs, exec passEnv, durable .env, generated service env defaults, and systemd EnvironmentFile rendering is preserved.

Review findings addressed

• RF-001: Maintainer/security decision boundary documented. This PR intentionally moves known Google/Gemini auth-profile credentials from inline systemd Environment= assignments into the existing generated 0600 EnvironmentFile path; current-head proof stages the unit and EnvironmentFile to show runtime delivery is preserved without inline plaintext.
• RF-002: Scope boundary documented. The file-backed auth-profile policy is limited to the known Google/Gemini credential names GEMINI_API_KEY, GEMINI_API_KEYS, GEMINI_API_KEY_0, and GOOGLE_API_KEY; a generic all-provider auth-profile service-env policy remains out of scope unless maintainers request that broader direction.
• RF-003: Manual-review boundary documented. The remaining auth-profile credential-rendering choice is security and compatibility sensitive, so the PR body calls out the canonical EnvironmentFile contract, unchanged paths, and exact current-head real behavior proof for maintainer/security review.
• Sync note: The branch has been synced onto current main, preserving fix(install): manage config-secretref env refs via OPENCLAW_SERVICE_MANAGED_ENV_KEYS #96065's config SecretRef managed-key behavior and resolving the conflict in src/commands/daemon-install-helpers.ts. The current diff only adds the remaining auth-profile value-source behavior plus its regression test.
• CI/type note: The Google provider fixture includes the required baseUrl; direct current-head run-tsgo.mjs core and extensions test type checks pass locally.

Regression Test Plan

• Target test file: src/commands/daemon-install-helpers.test.ts
• Scenario locked in: A gateway install plan receives GEMINI_API_KEY from a config SecretRef and GOOGLE_API_KEY from an auth-profile env ref; both must keep their values in the plan and be marked environmentValueSources: "file", while current main's OPENCLAW_SERVICE_MANAGED_ENV_KEYS=GEMINI_API_KEY behavior remains intact.
• Why this is the smallest reliable guardrail: The regression locks the install-plan source metadata because systemd staging uses that metadata to decide whether a value is rendered inline or through the generated EnvironmentFile.
• node scripts/run-vitest.mjs src/commands/daemon-install-helpers.test.ts
• ./node_modules/.bin/oxfmt --check src/commands/daemon-install-helpers.ts src/commands/daemon-install-helpers.test.ts
• node scripts/run-oxlint.mjs --tsconfig config/tsconfig/oxlint.core.json src/commands/daemon-install-helpers.ts src/commands/daemon-install-helpers.test.ts
• node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test-after-sync.tsbuildinfo
• node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.extensions.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/extensions-test-after-sync.tsbuildinfo
• git diff --check
• PROOF_HEAD=$(git rev-parse HEAD) ./node_modules/.bin/tsx /media/vdb/code/ai/aispace/openclaw-issue-95895-evidence/gemini-managed-env-proof.mts

Risk / Compatibility

Risk is limited to Google/Gemini auth-profile env-ref service rendering. Other provider auth-profile env refs keep the existing inline behavior, and current-main config SecretRef managed-key behavior is unchanged.

• What did NOT change: The patch does not change generic config SecretRef behavior, non-Google/Gemini auth-profile env-ref behavior, exec passEnv, generated service env defaults, or renderer behavior outside these Google/Gemini env key names.
• Architecture / source-of-truth check: buildGatewayInstallPlan is the source-of-truth contract for service env values and their environmentValueSources; systemd staging already treats file sources as generated EnvironmentFile values.
• Patch quality notes: This is not a fallback or string scrubber in the renderer. The change updates the owner metadata before rendering, so every downstream systemd staging path gets the same file-backed contract.
• Maintainer-ready confidence: High for the file-generation boundary tested here: the proof runs the production install-plan and systemd staging code, verifies no unit plaintext assignment, verifies EnvironmentFile delivery, checks mode 0600, and includes the synced target tests, formatting check, lint check, type-check shard, and whitespace check.

The generated systemd service still receives the Google/Gemini values because the change uses the existing file-backed EnvironmentFile path rather than dropping the values from the plan.

What was not changed

• Did not change current main's config SecretRef managed-key behavior.
• Did not change non-Google/Gemini auth-profile env-ref behavior.
• Did not change exec passEnv handling.
• Did not change the systemd renderer, EnvironmentFile writer, launchd renderer, or scheduled-task renderer.
• Did not add repro/proof files to the repository.

Root Cause

• Root cause: Google/Gemini auth-profile env refs used the default inline service env value source, so systemd rendering treated them as unit Environment= assignments.
• Why this is root-cause fix: The service env plan is the source of truth for how systemd should render each service env value. Marking these Google/Gemini auth-profile env-ref values as file-backed routes them through the existing generated EnvironmentFile path, which removes plaintext unit assignments while preserving runtime delivery.