Wrong auth-presence check for google-vertex

hasAnthropicVertexAvailableAuth is imported from anthropic-vertex-auth-presence.ts and returns true when ANTHROPIC_VERTEX_USE_GCP_METADATA=1 even with no ADC file on disk. If a user sets that env var (for their Anthropic Vertex setup) but has no application_default_credentials.json, this block returns the GCP_VERTEX_GOOGLE_CREDENTIALS_MARKER sentinel — but resolveGoogleVertexAccessToken in google-vertex-adc.ts then reads the ADC file, gets null, and the request fails at runtime with no helpful error.

The equivalent check for Google's ADC presence is hasGoogleVertexAvailableAuth (already exported from extensions/google/vertex-region.ts), but since that lives in the extension package it can't be imported here directly. The same gating logic that the extension's catalog uses (canReadAdc) should be replicated in core — similar to how canReadAnthropicVertexAdc is defined locally in anthropic-vertex-auth-presence.ts. A minimal fix is to inline an ADC-file-readable check here, or add a dedicated hasGoogleVertexAdcAvailableAuth helper in a new google-vertex-auth-presence.ts alongside its Anthropic sibling.

This is a comment left during a code review.
Path: src/agents/model-auth-env.ts
Line: 45-46

Comment:
**Wrong auth-presence check for `google-vertex`**

`hasAnthropicVertexAvailableAuth` is imported from `anthropic-vertex-auth-presence.ts` and returns `true` when `ANTHROPIC_VERTEX_USE_GCP_METADATA=1` *even with no ADC file on disk*. If a user sets that env var (for their Anthropic Vertex setup) but has no `application_default_credentials.json`, this block returns the `GCP_VERTEX_GOOGLE_CREDENTIALS_MARKER` sentinel — but `resolveGoogleVertexAccessToken` in `google-vertex-adc.ts` then reads the ADC file, gets `null`, and the request fails at runtime with no helpful error.

The equivalent check for Google's ADC presence is `hasGoogleVertexAvailableAuth` (already exported from `extensions/google/vertex-region.ts`), but since that lives in the extension package it can't be imported here directly. The same gating logic that the extension's catalog uses (`canReadAdc`) should be replicated in core — similar to how `canReadAnthropicVertexAdc` is defined locally in `anthropic-vertex-auth-presence.ts`. A minimal fix is to inline an ADC-file-readable check here, or add a dedicated `hasGoogleVertexAdcAvailableAuth` helper in a new `google-vertex-auth-presence.ts` alongside its Anthropic sibling.

How can I resolve this? If you propose a fix, please make it concise.

Service-account ADC type silently falls through

Only authorized_user credentials are exchanged for a token; all other ADC types (most commonly service_account JSON key files) reach the final return null with no diagnostic. Production GCP workloads typically use service-account keys, so this creates a confusing silent failure. Consider throwing or logging a clear message when the ADC file is present but its type is unhandled, so users aren't left wondering why auth is failing.

This is a comment left during a code review.
Path: src/agents/google-vertex-adc.ts
Line: 81-98

Comment:
**Service-account ADC type silently falls through**

Only `authorized_user` credentials are exchanged for a token; all other ADC types (most commonly `service_account` JSON key files) reach the final `return null` with no diagnostic. Production GCP workloads typically use service-account keys, so this creates a confusing silent failure. Consider throwing or logging a clear message when the ADC file is present but its `type` is unhandled, so users aren't left wondering why auth is failing.

How can I resolve this? If you propose a fix, please make it concise.

Duplicated marker constant

GCP_VERTEX_GOOGLE_CREDENTIALS_MARKER is defined as a private constant in both this file and vertex-region.ts (and exported from src/agents/model-auth-markers.ts). Within the extension package, vertex-provider-catalog.ts could import it from ./vertex-region.js if it were exported there, avoiding silent value drift if the marker is ever renamed.

This is a comment left during a code review.
Path: extensions/google/vertex-provider-catalog.ts
Line: 13

Comment:
**Duplicated marker constant**

`GCP_VERTEX_GOOGLE_CREDENTIALS_MARKER` is defined as a private constant in both this file and `vertex-region.ts` (and exported from `src/agents/model-auth-markers.ts`). Within the extension package, `vertex-provider-catalog.ts` could import it from `./vertex-region.js` if it were exported there, avoiding silent value drift if the marker is ever renamed.

How can I resolve this? If you propose a fix, please make it concise.

Support non-user ADC credentials for Vertex auth

The new Vertex token resolver only exchanges tokens when the ADC file is type: "authorized_user"; all other ADC types fall through with no token. In environments that use service-account ADC (GOOGLE_APPLICATION_CREDENTIALS in CI/GKE/Cloud Run), this makes runtime auth unresolved and requests end up unauthenticated (or sent with the marker as an API key), causing Vertex calls to fail consistently. Please add token minting for service-account/metadata ADC or refuse to advertise Vertex auth when the ADC type is unsupported.

Useful? React with 👍 / 👎.

Gate google-vertex env auth with the correct capability check

The google-vertex branch uses hasAnthropicVertexAvailableAuth, which can return true via Anthropic-specific metadata opt-in even when Google Vertex cannot actually resolve a token in this implementation. That emits the gcp-vertex-google-credentials marker and leads to failed runtime auth for google-vertex configs without readable Google ADC credentials. This should use a Google-specific availability predicate that matches what the Google resolver can truly handle.

Useful? React with 👍 / 👎.

Recompute Vertex location when baseUrl is overridden

Merging implicit and configured provider settings allows existing.baseUrl to override the implicit endpoint, but the region/header state is not recomputed from that effective URL. As a result, users who set models.providers.google-vertex.baseUrl to another region can still send /locations/us-central1/... paths, which causes Vertex INVALID_ARGUMENT request routing failures. The merge should derive location from the final base URL (or synchronize headers accordingly).

Useful? React with 👍 / 👎.

Strip path from Vertex baseUrl before composing request URL

This URL builder uses the full configured baseUrl as the prefix and then appends /v1/projects/..., so a valid override like https://us-central1-aiplatform.googleapis.com/v1 produces .../v1/v1/projects/... and Vertex requests fail. This commit newly supports google-vertex baseUrl overrides, so users who copy a /v1 endpoint form will get hard request failures until the builder normalizes to URL origin (or strips an existing /v1) before appending the path.

Useful? React with 👍 / 👎.

Preserve explicit session streamFn for google-vertex models

This new provider-specific branch returns a boundary-aware stream function before the existing custom-stream fallback, so any explicitly supplied currentStreamFn is ignored whenever model.provider === "google-vertex". That is a behavior regression for integrations that attach custom stream wrappers (for telemetry, retries, policy checks, etc.), because those wrappers now silently stop running for Vertex models.

Useful? React with 👍 / 👎.

Preserve prequalified Vertex model IDs in request paths

The Vertex URL builder always prefixes non-publishers/ model IDs with publishers/google/models/, so inputs like models/gemini-2.5-pro or tunedModels/... become invalid paths such as .../publishers/google/models/models/.... This causes Vertex requests to fail for model ID formats that are already accepted in the non-Vertex Google path logic, so the builder should treat already-qualified IDs as complete instead of blindly prefixing.

Useful? React with 👍 / 👎.

Prefer ADC project_id over quota_project_id for routing

This resolves the ADC project as quota_project_id before project_id, which conflicts with the implicit provider project resolution (in extensions/google/vertex-region.ts) that prefers project_id first. Because request URL construction prioritizes the token-derived project, ADC files containing both fields can route calls to the quota/billing project instead of the intended Vertex project, leading to avoidable permission or not-found failures.

Useful? React with 👍 / 👎.

Fail fast when Vertex project ID is unavailable

When baseUrl is a Vertex endpoint but no project id can be resolved (no GOOGLE_CLOUD_PROJECT, no provider header, and no ADC-derived project), this code falls back to the generic Gemini URL shape (.../models/...) on the Vertex host instead of returning a clear configuration error. That request shape is invalid for Vertex and will fail at runtime with a confusing API error, so users with ADC credentials lacking project metadata get broken requests rather than actionable guidance.

Useful? React with 👍 / 👎.

Let Vertex request URL infer location from endpoint

When ADC is used, this helper always injects a location field and defaults it to "us-central1"; later buildGoogleRequestUrl prioritizes that value over the endpoint-derived region. In configs that point baseUrl at another Vertex region (or the global host) without explicitly setting x-openclaw-vertex-location, requests are routed to /locations/us-central1/... on the wrong endpoint and fail with Vertex routing/INVALID_ARGUMENT errors. Leave location unset unless it is explicitly known so URL construction can fall back to the base URL region.

Useful? React with 👍 / 👎.

Import Vertex hook bundle before provider registration

This spread references GOOGLE_GEMINI_PROVIDER_HOOKS_WITH_TOOL_COMPAT, but that identifier is never defined or imported in this module. When register(api) runs, evaluating this object literal throws a ReferenceError, which aborts Google plugin registration and prevents the new Vertex provider from being registered at runtime. Please import the hook bundle (and the other newly referenced helpers below) before constructing this provider object.

Useful? React with 👍 / 👎.

Prefer exact provider ownership for google-vertex hooks

Registering a real google-vertex provider here collides with the existing google hook alias (hookAliases: ["google-vertex"] in extensions/google/provider-registration.ts), and runtime hook resolution uses first-match semantics (resolveProviderRuntimePlugin(...).find(matchesProviderId)). In that ordering, google can claim google-vertex first, so this provider's custom hooks (especially formatApiKey and refreshOAuth) are skipped; in auth-profile flows that means the raw OAuth access token is used instead of the JSON Bearer payload expected by parseGeminiAuth, leading to malformed Vertex auth. Ensure exact provider-id matches win (or remove the legacy alias) when google-vertex is registered.

Useful? React with 👍 / 👎.