Summary

• Problem: google-vertex only accepted file-based authorized_user ADC, so GCE Docker installs with attached VM service accounts could not authenticate even though Vertex AI worked directly.
• Why it matters: GCE service-account ADC should work without gcloud auth application-default login or downloaded service-account keys.
• What changed: Added GCE metadata token fallback for Vertex ADC, taught runtime auth, models status --probe, and doctor to recognize provider-declared live metadata auth, and routed local simple-completion Vertex calls through the OpenClaw Google Vertex transport.
• What did NOT change (scope boundary): No new service-account key handling, no gcloud login requirement, no broad provider auth rewrite.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: Google Vertex auth was gated on local authorized_user ADC discovery before the provider transport was exposed, and the ADC header resolver threw when no local ADC file existed or when the local ADC file was not authorized_user.
• Missing detection / guardrail: Tests covered authorized_user ADC refresh, but not VM-attached service-account ADC through the GCE metadata server, nor probe/doctor discovery for live provider auth evidence.
• Contributing context (if known): Docker on GCE can call Vertex AI successfully with the attached VM service account even when no local ADC JSON exists.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/google/transport-stream.test.ts, src/agents/model-auth-live-evidence.test.ts, src/commands/models/list.probe.targets.test.ts, src/commands/models/list.status.test.ts, src/commands/doctor-memory-search.test.ts.
• Scenario the test should lock in: no local ADC file plus metadata token succeeds; non-authorized_user ADC plus metadata token succeeds; unavailable metadata still throws the credential error; status/probe/doctor can discover live metadata auth without persisting tokens.
• Why this is the smallest reliable guardrail: It covers the provider-owned ADC resolver plus the generic auth evidence surfaces that previously hid the provider from probe/doctor.
• Existing test that already covers this (if any): Existing authorized_user ADC refresh coverage remains unchanged.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• google-vertex can authenticate on GCE using the VM's attached service-account token from the metadata server when local ADC is absent or not authorized_user.
• models status --probe and openclaw doctor recognize this as GCE metadata service account auth evidence.
• Local infer model run --model google-vertex/... uses the OpenClaw Google Vertex transport path.

Diagram (if applicable)

Before:
[google-vertex on GCE] -> [no authorized_user ADC file] -> [provider unavailable/auth failure]

After:
[google-vertex on GCE] -> [metadata token probe] -> [Bearer token for Vertex request]

Security Impact (required)

• New permissions/capabilities? (Yes/No): No
• Secrets/tokens handling changed? (Yes/No): Yes
• New/changed network calls? (Yes/No): Yes
• Command/tool execution surface changed? (Yes/No): No
• Data access scope changed? (Yes/No): No
• If any Yes, explain risk + mitigation:
  • The Google Vertex provider can now request a VM service-account access token from the GCE metadata server when local ADC is absent or not authorized_user.
  • The request is fixed to Google’s metadata token URL, sends Metadata-Flavor: Google, has a 1s timeout, returns undefined on failure, and does not persist or log the access token.
  • models status --probe and doctor expose only the non-secret gcp-vertex-credentials marker/source, not the token.
  • This follows OpenClaw's documented trusted-operator/plugin trust model in SECURITY.md; the provider plugin is part of the gateway TCB. It also intentionally differs from generic user-controlled URL fetch surfaces documented in docs/security/network-proxy.md because this is a provider-owned fixed metadata endpoint for ADC.

Repro + Verification

Environment

• OS: Linux VM on GCE
• Runtime/container: Docker Compose OpenClaw CLI/Gateway container
• Model/provider: google-vertex/gemini-3.1-pro-preview
• Integration/channel (if any): N/A
• Relevant config (redacted): GOOGLE_CLOUD_PROJECT, GOOGLE_CLOUD_LOCATION, attached VM service account; no service-account key file required.

Steps

1. Run OpenClaw in Docker on a GCE VM with an attached service account that can call Vertex AI.
2. Configure default model as google-vertex/gemini-3.1-pro-preview.
3. Run models status --probe --probe-provider google-vertex.
4. Run infer model run --gateway --model google-vertex/gemini-3.1-pro-preview --prompt "Say exactly: vertex ok".

Expected

• Status/probe detects source=GCE metadata service account and probes Vertex successfully.
• Inference returns vertex ok.

Actual

• Before this change, the provider required local authorized_user ADC and failed without a local ADC JSON file.
• After this change, the GCE metadata service-account token path succeeds.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Verification run locally through the Docker compose CLI image because host node/pnpm were not on PATH:

• pnpm docs:list
• pnpm exec oxfmt --check --threads=1 CHANGELOG.md docs/auth-credential-semantics.md docs/cli/models.md docs/plugins/manifest.md docs/providers/google.md extensions/google/index.test.ts extensions/google/openclaw.plugin.json extensions/google/provider-registration.ts extensions/google/transport-stream.test.ts extensions/google/vertex-adc.ts src/agents/model-auth.ts src/agents/model-auth-live-evidence.ts src/agents/model-auth-live-evidence.test.ts src/agents/provider-transport-stream.ts src/agents/provider-transport-stream.test.ts src/agents/simple-completion-transport.ts src/agents/simple-completion-transport.test.ts src/commands/doctor-memory-search.test.ts src/commands/doctor-memory-search.ts src/commands/models/list.auth-overview.ts src/commands/models/list.probe.targets.test.ts src/commands/models/list.probe.ts src/commands/models/list.status-command.ts src/commands/models/list.status.test.ts src/plugins/manifest-registry.test.ts src/plugins/manifest.ts src/secrets/provider-env-vars.dynamic.test.ts src/secrets/provider-env-vars.ts
• pnpm test extensions/google/transport-stream.test.ts extensions/google/index.test.ts src/agents/model-auth-live-evidence.test.ts src/agents/provider-transport-stream.test.ts src/agents/simple-completion-transport.test.ts src/commands/models/list.probe.targets.test.ts src/commands/models/list.status.test.ts src/commands/doctor-memory-search.test.ts src/plugins/manifest-registry.test.ts src/secrets/provider-env-vars.dynamic.test.ts -- --reporter=verbose
• pnpm docs:check-i18n-glossary
• git diff --check

Manual live proof from GCE Docker:

- google-vertex effective=env:gcp-vert...dentials | env=gcp-vert...dentials | source=GCE metadata service account
Auth probes: google-vertex/gemini-3.1-pro-preview ok
model.run via gateway -> output: vertex ok

Human Verification (required)

• Verified scenarios: metadata ADC success with no local ADC; metadata unavailable fallback error; non-authorized_user ADC falling through to metadata; existing authorized_user ADC refresh behavior; status/probe/doctor auth evidence discovery; local simple-completion Vertex transport selection.
• Edge cases checked: non-OK metadata response, malformed metadata JSON, missing token, required env gates, token not persisted/logged, non-secret marker in auth overview.
• What you did not verify: Full pnpm check/full pnpm test; only focused touched-surface tests plus live Docker/GCE proof were run.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No): Yes
• Config/env changes? (Yes/No): Yes
• Migration needed? (Yes/No): No
• If yes, exact upgrade steps: Existing local authorized_user ADC behavior is unchanged. GCE metadata ADC requires GOOGLE_CLOUD_PROJECT or GCLOUD_PROJECT, plus GOOGLE_CLOUD_LOCATION, and an attached VM service account with Vertex AI permission.

Risks and Mitigations

• Risk: Non-GCE environments could be slowed by metadata probing.
  • Mitigation: Metadata probes are gated by explicit Google Cloud project/location env evidence and use a 1s abort timeout.
• Risk: Metadata access tokens could leak through status/probe output.
  • Mitigation: Runtime requests use the token only in-memory for Authorization; status/probe/doctor return the non-secret gcp-vertex-credentials marker and source label only.