fix: pass Vertex project explicitly to ChatGoogle; drop setup-time ping call

[ppsplus-bradh]

Hi @ernani — this is a small helper PR targeting your gemini-support branch to address @rajpratham1's review on langchain-ai#36. Merge it into your branch and it will roll into that PR. Feel free to cherry-pick instead if you prefer.

What the review asked

gemini-enterprise uses GOOGLE_CLOUD_PROJECT as its "API key" env var and even writes the entered value into process.env.GOOGLE_CLOUD_PROJECT before constructing ChatGoogle. However, ChatGoogle is instantiated without explicitly passing the project ID, relying on ambient environment state instead… it would be better to pass the project ID explicitly to ChatGoogle and keep the provider configuration aligned with how the SDK expects GCP settings.

Changes

• Pass the project explicitly. createModel()'s gemini-enterprise branch now reads GOOGLE_CLOUD_PROJECT and passes it as googleAuthOptions: { projectId } to ChatGoogle, rather than relying on ambient process.env resolution.
• Use the Node auth entrypoint. Import ChatGoogle from @langchain/google/node. The default @langchain/google entrypoint types authOptions as never and is API-key oriented, so googleAuthOptions isn't available there. It's the same package (no new dependency), and the /node client still supports the AI Studio gai/apiKey path used by the gemini provider.
• Drop the setup-time validation call in credentials.tsx that mutated process.env.GOOGLE_CLOUD_PROJECT and issued a live testModel.invoke([{ role: "user", content: "ping" }], { timeout: 5000 }) during onboarding. That was the source of the flagged process.env mutation, and it also added a network round-trip, cost, and a potential hang that no other provider performs at setup.

Verified: pnpm run build, pnpm run lint:check, and prettier --check on the changed files all pass; runtime construction of ChatGoogle succeeds for the gcp+projectId, gcp (ambient ADC), and gai paths.

Note: this keeps GOOGLE_CLOUD_PROJECT as the provider's credential env key (the credential gate still works), so the diff stays minimal. Fully re-modeling GCP settings as their own credential fields (rather than reusing apiKeyEnvKey) would be a larger change to the shared credential/step machine — happy to follow up on that separately if you and the reviewer want it.

🤖 Generated with Claude Code

[ernani]

Thanks for the suggestion @ppsplus-bradh I unfortunately left for vacation but saw that things got caught up and implemented nonetheless! Glad to see this going through!