[CRITICAL/P0] v2.73.0 aggressively injects unauthorized GCP Shadow Project IDs into active VS Code Configuration API for Individual AI Pro Users, bypassing OS-level Read-Only file locks

[mdatd94]

[CRITICAL/P0] v2.73.0 aggressively injects unauthorized GCP Shadow Project IDs into active VS Code Configuration API for Individual AI Pro Users, bypassing OS-level Read-Only file locks

Environment:

• Subscription Tier: Google One AI Premium (Individual)
• Authentication Flow: "Gemini for Individuals"
• Note: This issue survives a total OS wipe, %APPDATA% nuclear reset, and account change. It was reproduced on a brand-new Google account with a newly purchased subscription.

Version information
Cloud Code Extension version: Gemini Code Assist v2.73.0
VSCode version: 1.87.0
OS: Windows 11 (Fresh Installation)
Cloud SDK: N/A (Individual subscriber, not an enterprise GCP user)
Skaffold: N/A
Kubectl: N/A

Description:
There is a fundamental authentication routing flaw and aggressive configuration-injection bug in v2.73.0. When an Individual AI Pro subscriber logs in via the "Gemini for Individuals" flow, the extension incorrectly routes the token validation through the Google Cloud Platform (GCP) Enterprise pipeline.

This triggers the automatic generation of a default "shadow" GCP project (e.g., inlaid-matrix-n87pw, shining-osprey-687pw) on the server side.

The extension then actively bypasses standard user configuration preferences and forcefully injects this un-provisioned Project ID into the geminicodeassist.project key via VS Code's active Configuration API.

Because the Individual user lacks GCP IAM/Billing permissions for this auto-generated shadow project, all Agent/Yolo actions immediately fail with HTTP 403 / Invalid Argument errors, completely breaking the UX and creating an inescapable "Permission Denied" loop.

Impact: This completely breaks the extension for Individual tier users. All local mitigation strategies (including OS-level file locking) fail.

Repro step:

1. Install VS Code and the Gemini Code Assist extension (v2.73.0).
2. Open a workspace folder and create .vscode/settings.json with the override: "geminicodeassist.project": "".
3. Set the .vscode/settings.json file to Read-only at the OS level (Windows File Explorer).
4. Authenticate using the "Gemini for Individuals" web flow.
5. Observe the VS Code settings editor buffer at the exact moment the login handshake completes.

Actual Behavior: Within milliseconds, the extension forces the shadow project ID into the active VS Code editor buffer/configuration state, overriding the user's empty string. This occurs even if the underlying settings.json file is locked to "Read-only" at the OS level, proving the extension is maliciously injecting state into the live VS Code Configuration API rather than just modifying the disk file.

The user is instantly locked out of all AI features with "Invalid Project ID" and "Account lacks permission" errors.

---

Video Evidence / Attachments

Note: Due to GitHub's file size limits for direct video uploads, the unedited captures of the active configuration bypass are provided via the external links below.

Google Drive (Full Folder):

• Access all 6 evidence videos here

YouTube Links:

• Video 1: Initial Login Bypass
• Video 2: Configuration Injection
• Video 3: Workspace Overwrite
• Video 4: Settings Buffer Mutation
• Video 5: Read-Only Lock Failure

[SaminSadaf22]

faceing the same issue for a long time, GEMINI is a piece of shit. Use github copilot.

[mdatd94]

CRITICAL UPDATE: Server-Side Routing Confirmation (Not isolated to v2.73.0)

I downgraded the extension to v2.72 and wiped all local caches, but the exact same aggressive overwrite and Read-Only bypass continues to happen.

The extension sidebar explicitly displays: "To use Gemini Code Assist Standard or Enterprise, you need to select a Google Cloud project."

This confirms the root cause is a server-side OAuth routing bug, not a client-side extension bug. The Google identity backend is completely ignoring my "Individual" Google One AI Premium subscription tier. Instead, it is maliciously misclassifying my standard @gmail.com account as an Enterprise user upon login.

Because the backend is forcing an Enterprise payload down to the client, the extension strictly enforces the Enterprise project requirement, auto-generating the shadow project and forcefully injecting it into the active VS Code Configuration API (bypassing my OS read-only locks in the process).

The fix needs to happen on the backend authentication routing, as it is failing to recognize Individual tier tokens.