App Prototyping agent provisions a Firebase project and a Gemini API key for you

General
1

When creating a new project in Firebase Studio using App Prototyping agent, it should prompt me to add or generate a “Gemini API key”.

But, instead of showing the box for “Gemini API key”, a Firebase: Error (auth/invalid-api-key) appeared, then it tried to fix the error by “Update Firebase Initialization” & " Add Safety Checks". The problem is, it will not create the project in Firebase Console automatically.

shot_250707_124717
shot_250707_1247171919×1031 129 KB

If trying to Create API key in Google AI Studio, it will ask to “Select a project from your existing Google Cloud projects”, but a Google Cloud project will be created when OAuth 2.0 Client IDs is created automatically as “Web client (auto created by Google Service)”.

So, if I manually created a Google Cloud project, it seems a conflict. Is there a setup procedure to make this easier?

Thanks

2 Likes
2

Firebase CIM Field-Ops Analysis
MubieSam_Lin — your error is not a random auth glitch. It’s what I think is a procedural violation between your provisioning agent’s expectations and the existing GCP / API key state.

:small_blue_diamond: A — Role & Owner of API Key
Who “owns” the Gemini key? The agent must know this in order to work.

:small_blue_diamond: B — Key State & Existence
Check whether a Gemini API key already exists for that project. If so, adopt it; if not, create it — never patch mismatches.

:small_blue_diamond: C — Permissions
The agent’s service identity must have IAM scopes to create projects, API keys, link them. Lack of scope = guaranteed failure.

:small_blue_diamond: D — Bootstrapping Order
The agent’s provisioning sequence must be linear, non-branching. Fallback “safety patches” introduce chaos.

:small_blue_diamond: E — Idempotence / Rollback
If a step fails mid-course, rollback all prior steps so you don’t leave half-provisioned resources.

:pushpin: Directive

  1. Disable fallback patch logic;

  2. Enforce a single-path provisioning sequence with clearly observable and detectable barriers.

  3. Validate permissions before attempts;

  4. Rollback on failure;

  5. Surface explicit errors, not auto-patches.

create a Merged Map at each point to surface status to your Logs file

[FORWARD:ACTIVE] — after project creation
[FORWARD:GO] — on final commit
[FORWARD:ALERT] — interrupt on critical failure

When you can, determine which point is failing (e.g. “API key creation failed: insufficient permissions”) you should be able to move your project forward. Should your project continue to Error, I would advise Archiving the project and using the Dev notes to date to rebuild the project up to where you experienced your most prioritized pain point. I advise Users to dedicate 72 hrs. to reading the Documentation and making sure your project aligns with the Applications design intent and limitations.