Related Pages

Related topics: Deployment Lifecycle and Service Integrations

CLI Overview, Configuration, and Authentication

Purpose and Scope

firebase-tools is the official Firebase command-line interface (CLI) and Model Context Protocol (MCP) server. As stated in README.md, the project exposes a single firebase binary that surfaces commands for every Firebase product (Hosting, Realtime Database, Cloud Functions, Firestore, Authentication, Extensions, App Distribution, and more), while the same engine can be embedded as a long-lived MCP process for AI-assisted workflows.

The repository is a TypeScript project. The published artifact includes lib, prompts, schema, standalone, and templates directories as configured in package.json:files. The package is published to a private Google registry (wombat-dressing-room) and the runtime contract is declared as Node.js >=20.0.0 || >=22.0.0 || >=24.0.0 in package.json:engines. The CLI is marked preferGlobal: true, meaning npm is expected to install it as a global command rather than a project dependency.

Command Surface

The README organizes the CLI into product-specific command groups, each listed as a Markdown table. Representative groups documented in README.md include:

Two cross-cutting commands are also visible in the README: firebase login / firebase logout and firebase init, which together form the configuration and authentication loop covered in the next section.

Configuration Model

firebase-tools reads project-level configuration from a firebase.json file at the root of a project. The init command scaffolds this file by writing the schema-validated object that subsequent commands (such as deploy or emulators:start) consume. The schema definitions are bundled into the published artifact under the schema/ entry listed in package.json:files, enabling editors and CI pipelines to validate configuration offline.

Per-user, per-project metadata (such as aliases and the active project) is stored in a separate .firebaserc file that is read and written by the CLI. Recent releases have tightened validation around this configuration: release v15.13.0 added a check that the backendId referenced via the --only flag actually exists in firebase.json (issue #10161), and v15.17.0 fixed an error when multiple Firestore databases were configured in a single firebase.json (issue #8114). The v15.14.0 release also added a new firestore.edition key (and an equivalent emulators.firestore.edition) for switching the local Firestore emulator to Enterprise Edition.

The VS Code extension bundled in this monorepo reads the same firebase.json shape. For example, firebase-vscode/src/data-connect/code-lens-provider.ts consumes the parsed Data Connect configuration (fdcConfigs) to decide which CodeLenses to surface for a given SQL/GraphQL document, demonstrating that firebase.json is the single source of truth across editor, CLI, and MCP contexts.

Authentication

Authentication is performed against Google user credentials and is exposed in two complementary ways.

Human-driven login

The classic firebase login and firebase logout commands open a browser-based OAuth flow against a Google account and persist the resulting refresh token locally so that subsequent commands (deploys, emulator projects, auth:export, etc.) can act on the user's behalf. The firebase init flow in README.md walks the user through selecting which products to configure after authentication succeeds.

Agent-driven login (MCP)

When the CLI runs as an MCP server (firebase experimental:mcp), the same login capability is exposed as discrete tools. The reference server described in src/mcp/README.md and the parallel antigravity variant in src/mcp/antigravity/README.md both ship the following core authentication tools:

The MCP server also bundles reusable prompts and resources that operate on the authenticated session. The firebase:deploy and firebase:init prompts in src/mcp/antigravity/README.md are designed to be invoked after firebase_login has succeeded, while resources such as backend_init_guide and firestore_rules_init_guide provide the agent with the up-to-date configuration knowledge it needs to drive init correctly. A recent fix in v15.17.0 (issue #10437) corrected a schema-validation error that caused some MCP tools to fail with Invalid input: expected record, received array, which previously disrupted this agent-driven login-and-init flow.

The Auth Emulator

For local development, the Authentication surface is emulated in-process. According to src/emulator/auth/README.md, the emulator is generated by first converting the Google Identity Platform REST discovery documents into a single merged OpenAPI 3.0 specification (apiSpec.js), and then mounting that spec at runtime through the exegesis-express library. This gives the emulator schema-validated request handling that mirrors production, while the implementation of each operation lives in operations.ts and is keyed by its OpenAPI operation ID (for example identitytoolkit.accounts.signUp). The same emulator is consumed by auth:import/auth:export flows when run against emulators:start.

Common Failure Modes

A few failure modes recur in the community context and are worth flagging for new users:

• Restored but soft-deleted projects. A restored Firebase project can still surface PROJECT_SOFT_DELETED from Auth and Firestore until backend reconciliation completes (issue #10603). Re-authenticating with firebase login and re-selecting the project with firebase use <projectId> is usually required.
• Functions deploy regressions. Issue #10590 documents a v1 Cloud Functions LIST API regression that blocked all firebase deploy --only functions for gen2-only projects for over 24 hours; rolling back to an earlier firebase-tools release or upgrading past the fix is the typical workaround.
• MCP tool input validation. Pre-v15.17.0 MCP servers could fail with Invalid input: expected record, received array for some Firestore and Auth tools (issue #10437); upgrading the CLI resolves the validator mismatch.

See Also

• README.md — full command reference and quick-start
• src/mcp/README.md and src/mcp/antigravity/README.md — MCP server tool, prompt, and resource catalogs
• src/emulator/auth/README.md — Authentication emulator architecture
• package.json — engine support, published artifact, and build scripts

Related Pages

Related topics: CLI Overview, Configuration, and Authentication, Emulator Suite, Hosting Server, and Framework Support

Deployment Lifecycle and Service Integrations

Purpose and Scope

The Deployment Lifecycle and Service Integrations in firebase-tools describes how the firebase deploy command orchestrates multi-service rollouts, how user-defined lifecycle hooks intercept those rollouts, and how CLI-level targeting (e.g. --only functions,hosting) maps to specific product backends. The CLI is the single entry point for shipping code and configuration to Firebase products, and it is the surface where most of the user-visible regressions in the project appear.

The top-level CLI is published as a Node.js package (firebase-tools) with declared Node engine compatibility >=20.0.0 || >=22.0.0 || >=24.0.0 and ships pre-built artifacts under lib/, prompts/, schema/, standalone/, and templates/ (package.json:20-24,27-30). The binary exposes commands grouped by product, including Hosting, Cloud Functions, Cloud Firestore, Realtime Database, Extensions, App Distribution, and Auth (README.md command tables).

High-Level Deploy Flow

The deploy command resolves the active Firebase project, parses target filters, dispatches to per-service deployers, and exposes pre/post hooks. The following diagram summarizes the lifecycle.

flowchart TD
    A[firebase deploy invocation] --> B[Resolve project & firebase.json]
    B --> C[Parse --only / --except target filters]
    C --> D{Filter valid?}
    D -- No --> Z[Abort with diagnostic]
    D -- Yes --> E[Run predeploy lifecycle hooks]
    E --> F[Dispatch to per-service deployers]
    F --> G1[Hosting]
    F --> G2[Cloud Functions]
    F --> G3[Firestore rules/indexes]
    F --> G4[Realtime Database rules]
    F --> G5[Extensions]
    F --> G6[App Distribution]
    F --> G7[Auth config]
    G1 --> H[Run postdeploy lifecycle hooks]
    G2 --> H
    G3 --> H
    G4 --> H
    G5 --> H
    G6 --> H
    G7 --> H
    H --> I[Final summary report]

The target-filter pipeline is a recurring source of bugs. Recent releases tightened validation: v15.13.0 added validation that checks whether backendId referenced in --only exists in firebase.json (release notes cite PR #10161), and v15.14.0 fixed a long-standing issue where functions deployments could silently fail (issue #6989) plus a PowerShell argument-parsing regression (#7506).

Service Integrations

Hosting, Functions, and Data

Hosting integration covers deploy, channel management, and disable, with the full command surface listed in the project README (README.md, *Hosting Commands* table). Functions deployment is the most actively-evolved integration: v15.15.0 introduced foundation work to be smarter about region placement when region is unspecified (#10293), and v15.18.0 resolves undefined regions earlier during the build-to-backend resolution phase (#10471).

Functions deployment is also where secret bindings live. Issue #10597 documents a community request to support loose binding / aliasing for existing GCP Secrets in defineSecret, since the current contract requires the GCP Secret Manager secret ID to match the parameter name exactly. Functions also gained an experimental Dart SDK behind the dartfunctions flag in v15.15.0, and issue #10591 requests a way to use a folder other than bin to work around Dart build-hook issues.

Firestore and Realtime Database

Firestore deploys support rules, indexes, and (since v15.17.0) search-index creation (#10431). The v15.14.0 release added Enterprise Edition support to the Firestore emulator, configurable via firebase.json#firestore.edition or firebase.json#emulators.firestore.edition. v15.16.0 updated the Firestore Emulator to v1.21.0 (subqueries, let(...) stages, per-database edition). v15.17.0 also fixed an MCP error ("Invalid input: expected record, received array") and resolved errors when multiple Firestore databases are configured in firebase.json (#8114).

Realtime Database deploys rules via database:settings:set and exposes CRUD commands listed in README.md (*Realtime Database Commands* table).

Auth, Extensions, and App Distribution

Auth deploys via the auth:import and auth:export commands. v15.19.0 added six more identity providers to these commands and fixed CSV escaping for double quotes (#3484). The local Auth emulator is implemented as an Express app driven by an OpenAPI 3.0 spec converted from Google API Discovery documents; the conversion script lives at scripts/gen-auth-api-spec.ts and the merged spec is loaded by exegesis-express in src/emulator/auth/server.ts, with operation handlers keyed by ID in src/emulator/auth/operations.ts (src/emulator/auth/README.md:5-23).

Extensions and App Distribution commands are listed in README.md and follow the same firebase deploy lifecycle, with per-extension instance configuration via ext:configure and ext:install.

Agent-Driven and IDE Integrations

Beyond the CLI binary, deployment workflows are exposed to AI agents through the Firebase MCP server, which provides tools (firebase_login, firebase_deploy, firebase_validate_security_rules, firestore_get_document, auth_get_users, apphosting_list_backends, etc.), prompts (firebase:deploy, firebase:init, firebase:consult), and resources (init guides for backend, GenAI, SQL Connect, Firestore, Hosting, Auth) — see src/mcp/README.md and src/mcp/antigravity/README.md.

The agent evaluation harness at scripts/agent-evals/src/runner/gemini-cli-runner.ts exercises these tools against the real CLI: it points the Gemini CLI at a local telemetry log, swaps the firebase binary for a mock main (scripts/agent-evals/src/mock/mock-tools-main.js) when running mocked tool suites, and tracks a per-turn turnToolIndex so previous tool calls are not double-counted.

The VS Code extension at firebase-vscode/src/data-connect/code-lens-provider.ts surfaces deployment-adjacent actions (Generate Query, Configure Generated SDK) as in-editor CodeLenses tied to Data Connect schema and connector files.

Common Failure Modes

From community evidence, the most-reported lifecycle issues are:

See Also

• README.md — full command reference.
• src/mcp/README.md — MCP server tools, prompts, and resources.
• src/emulator/auth/README.md — Auth emulator architecture.
• Release notes: v15.19.1, v15.18.0, v15.15.0, v15.13.0.

Related Pages

Related topics: Deployment Lifecycle and Service Integrations

Emulator Suite, Hosting Server, and Framework Support

Overview

The Firebase CLI (firebase-tools) ships a comprehensive Emulator Suite that allows developers to run Firebase services locally, a Hosting Server for local static and dynamic content serving, and Framework Support for popular web frameworks like Next.js and Angular. Together, these capabilities let engineers validate end-to-end Firebase workflows on their workstation before deploying to production. The CLI requires Node.js >=20.0.0, >=22.0.0, or >=24.0.0 as declared in package.json under the engines field (Source: package.json:30-32).

The Emulator Suite has been a focal point of community engagement for years, with highly-upvoted feature requests such as the long-standing "Add firebase authentication emulator to emulator suite" (issue #1677) and "Add Firestore indexes to local emulator" (issue #2027). These indicate that local-first development remains one of the most-requested capabilities in the Firebase ecosystem.

Emulator Suite

Auth Emulator Architecture

The Auth Emulator is built on top of an OpenAPI 3.0 specification generated from Google's Identity Platform discovery documents. As described in src/emulator/auth/README.md, the spec is generated by gen-auth-api-spec.ts and outputs a merged OpenAPI file (apiSpec.js) which is read at runtime by the exegesis-express library to set up Express routes with built-in JSON schema validation (Source: src/emulator/auth/README.md:15-30).

The runtime flow is:

1. server.ts loads apiSpec.js and registers the routes through exegesis-express.
2. exegesis invokes the corresponding operation method declared in operations.ts, identified by its OpenAPI operation ID (e.g., identitytoolkit.accounts.signUp).
3. The emulator serves the API spec at http://localhost:5002/emulator/openapi.json, which can be browsed via the Swagger Editor for interactive testing.

Emulator Lifecycle and Emulator Catalog

The Emulator Suite is designed to be modular. A central controller coordinates startup, port allocation, and shutdown of each downloadable emulator (Auth, Firestore, Functions, Pub/Sub, Storage, Realtime Database, SQL Connect, etc.). The recent release notes confirm ongoing catalog evolution: v15.14.0 added Enterprise Edition support to the Firestore emulator via firebase.json#firestore.edition, and v15.15.0 updated the Pub/Sub emulator to 0.8.30 (Source: README.md:database-commands).

Hosting Server

The Hosting Server is delivered through the superstatic dependency, which is bundled in package.json at version ^10.0.0 (Source: package.json:dependencies). Superstatic provides the local HTTP serving layer for firebase serve and the hosting channel of the Emulator Suite, handling clean URLs, rewrites, redirects, and headers defined in firebase.json.

Hosting Server and Static/Dynamic Asset Routing

The Hosting Server exposes a local URL (typically http://localhost:5000) that mirrors production Hosting behavior. It reads the hosting block of firebase.json and resolves:

• public — directory of static assets to serve.
• rewrites — URL rewrites including Cloud Functions and Cloud Run targets.
• redirects — 301/302/307/308 redirects.
• headers — custom response headers per glob.
• cleanUrls — extension stripping.

These directives are interpreted by the superstatic middleware, allowing the same firebase.json to be exercised both locally and on production Hosting without modification.

Framework Support

Web Framework Deploy Tests

Firebase Hosting includes first-class support for SSR/SSG frameworks. The repository ships a dedicated test harness at scripts/webframeworks-deploy-tests/ that exercises production-equivalent builds of two leading frameworks:

• Next.js — verified by scripts/webframeworks-deploy-tests/nextjs/package.json, which pins next 16.2.4, react 19.2.1, and react-dom 19.2.1 (Source: scripts/webframeworks-deploy-tests/nextjs/package.json:11-15).
• Angular — verified by scripts/webframeworks-deploy-tests/angular/src/index.html, which bootstraps an Angular app with <app-root> and a <base href="/"> element (Source: scripts/webframeworks-deploy-tests/angular/src/index.html:1-10).

The CLI detects the framework during firebase init hosting or firebase deploy and applies the correct build pipeline (e.g., next build for Next.js). The Next.js 16.2.4 reference in the test suite aligns with the v15.15.0 release notes that added a foundation for smarter region placement and the experimental Dart functions runtime, both of which are also surfaced to framework-aware deploys (Source: scripts/agent-evals/templates/next-app-hello-world/package.json:12-16).

Agent Eval Templates

Beyond manual CLI use, the repository also ships evaluation templates under scripts/agent-evals/templates/, including a Next.js hello-world app and a Crashlytics iOS sample (Source: scripts/agent-evals/templates/crashlytics-ios/README.md:1-5). These templates exercise the same framework-aware codepaths that production deploys use, providing regression coverage for new framework features.

Architecture Overview

flowchart LR
    Dev[Developer Machine] -->|firebase emulators:start| Controller[Emulator Controller]
    Controller --> Auth[Auth Emulator<br/>:5002]
    Controller --> FS[Firestore Emulator<br/>:8080]
    Controller --> FN[Functions Emulator<br/>:5001]
    Controller --> Hub[Emulator Hub<br/>:4000]
    Controller --> Hosting[Hosting Server<br/>:5000]
    Hosting --> Superstatic[superstatic middleware]
    Dev -->|firebase deploy| Framework[Framework Detector]
    Framework --> Next[Next.js pipeline]
    Framework --> Angular[Angular pipeline]
    Next --> Upload[Asset upload to Firebase]
    Angular --> Upload

Common Failure Modes and Community Workarounds

The community context surfaces several recurring emulator-related issues that engineers should be aware of:

• PROJECT_SOFT_DELETED after restore (issue #10603): restored projects can surface broken Auth/Firestore state, which the Auth Emulator will faithfully reproduce. Workaround: spin up a fresh emulator project ID to isolate state.
• "Failed to load function" intermittent failure (issue #10585): the Functions Emulator can fail to load a function definition without diagnostic output. Re-running with verbose logging and ensuring deterministic module resolution in package.json typically resolves this.
• Cloud Functions v1 LIST API regression (issue #10590): the firebase deploy --only functions flow can be blocked by an upstream 400 Precondition check failed. The deploy pipeline always calls the v1 LIST endpoint, so this is a CLI-side observable symptom of a server-side regression.

See Also

• Firebase MCP Server — AI-assistant integration documented in src/mcp/README.md.
• firebase deploy reference — Deploying Hosting, Functions, and database rules from the CLI.
• Firestore Emulator configuration — Enterprise Edition toggle via firestore.edition in firebase.json (introduced in v15.14.0).

Related Pages

Related topics: CLI Overview, Configuration, and Authentication, Deployment Lifecycle and Service Integrations

MCP Server, AI/Agent Tooling, and Extensions

The Firebase Model Context Protocol (MCP) server, the agent evaluation harness under scripts/agent-evals, and the Firebase VS Code extension form a coordinated ecosystem that lets AI-powered development tools act on Firebase projects and assist developers directly from their editor. This page describes the architecture, capability model, and supporting tooling for that ecosystem.

Firebase MCP Server

The Firebase MCP server ships inside the firebase-tools package and is started as the experimental:mcp subcommand. Any tool that can act as an MCP client can drive it, including Firebase Studio, Gemini CLI, Claude Code, Cline, Cursor, VS Code Copilot, and Windsurf. Source: src/mcp/README.md:1-15

For one-click installation in tools such as Cursor, the README exposes a deeplink that registers the server with the command npx -y firebase-tools@latest mcp. Source: src/mcp/README.md:3-5

The server implements the three MCP capability types:

• Tools – functions that perform actions against Firebase products.
• Prompts – reusable, parameterized command templates.
• Resources – documentation files the agent can pull on demand. Source: src/mcp/README.md:75-89

Login is performed through the firebase_login tool, which is a prerequisite for any operation that needs a project context. Other core tools include firebase_logout, firebase_validate_security_rules, firebase_get_project, firebase_list_apps, firebase_list_projects, and firebase_get_sdk_config. Source: src/mcp/antigravity/README.md:18-25

Product-Specific Tools

Tools are grouped by feature area. Representative groups include:

• Firestore – firestore_list_collections, firestore_query_collection, firestore_delete_document.
• Auth – auth_get_users, auth_update_user, auth_set_sms_region_policy.
• Data Connect / SQL Connect – dataconnect_build, dataconnect_list_services, dataconnect_execute, dataconnect_generate_schema, dataconnect_generate_operation.
• Crashlytics – crashlytics_get_top_issues, crashlytics_list_notes, crashlytics_update_issue, crashlytics_get_report.
• Realtime Database – realtimedatabase_get_data, realtimedatabase_set_data. Source: src/mcp/antigravity/README.md:30-65

Some tools depend on resources: for example, crashlytics_get_report requires the agent to first read the firebase://guides/crashlytics/reports resource via the firebase_read_resources tool, which couples the Resource and Tool primitives. Source: src/mcp/antigravity/README.md:50-55

A subset of tools (such as dataconnect_generate_schema and firebase:consult) are powered by Gemini in Firebase. The README explicitly warns that Gemini output may be plausible yet factually incorrect, and that no PII or user data should be passed in. Source: src/mcp/README.md:30-40

Prompts and Resources

The bundled prompts include firebase:deploy, firebase:init, firebase:consult, and crashlytics:connect. The deploy prompt accepts an optional free-form argument with specific deploy instructions. Source: src/mcp/antigravity/README.md:75-90

The bundled resources include backend_init_guide, ai_init_guide, data_connect_init_guide, firestore_init_guide, firestore_rules_init_guide, and rtdb_init_guide. Each is a Markdown file the agent can load to learn how to configure a Firebase product in the current project. Source: src/mcp/antigravity/README.md:95-108

Agent Evaluation Harness

A separate harness under scripts/agent-evals exercises the MCP server in real coding agents. It is built on Mocha and uses a local telemetry log to record every tool invocation made by the agent under test. Source: scripts/agent-evals/README.md:1-10

Running and Authoring Tests

The standard development loop links the local build of the CLI into the test environment and then runs the suite against a watch build:

npm link
npm run build:watch
cd scripts/agent-evals
npm run test:dev

Source: scripts/agent-evals/README.md:11-22

test:dev skips rebuilding the CLI to leverage the watch process, while npm run test performs a clean install for CI runs. The harness also warns that it will remove any existing Firebase MCP servers and the Firebase Gemini CLI extension from the user account, to keep the test environment hermetic. Source: scripts/agent-evals/README.md:1-10, scripts/agent-evals/README.md:23-28

A companion smoke-test package lives at scripts/mcp-tests and depends on @modelcontextprotocol/sdk and tsx, exposing a test script that runs a gemini-smoke-test.ts driver. Source: scripts/mcp-tests/package.json:1-15

Test Runner Internals

GeminiCliRunner writes a workspace settings.json that disables auto-update, enables local telemetry, and points the firebase MCP server at the harness' mock loader using --import mock-tools-main.js. The mock loader is resolved relative to getAgentEvalsRoot(), and the set of active mocks is communicated to the CLI via the TOOL_MOCKS environment variable. Source: scripts/agent-evals/src/runner/gemini-cli-runner.ts:15-50

InteractiveCLI has no explicit "turn complete" signal from the Gemini CLI, so waitForTurnComplete polls the output buffer and considers the turn done once the buffer has been unchanged for repetitionsUntilComplete (default 3) consecutive polls. waitForText similarly polls for a case-insensitive substring or regex match against the ANSI-stripped output. Source: scripts/agent-evals/src/runner/interactive-cli.ts:25-45

Tool Mocking

Mocks replace an MCP tool's behavior with a static string response. A new mock is added under scripts/agent-evals/src/mock/mocks/, registered in the allToolMocks map, and then activated by passing its name in the TOOL_MOCKS env var. The toMockContent helper wraps a plain string in the { content: [{ type: "text", text }] } shape that MCP tool responses expect. Source: scripts/agent-evals/README.md:40-65, scripts/agent-evals/src/mock/tool-mock-utils.ts:1-5

Editor Integration: Firebase VS Code Extension

The Firebase VS Code extension augments the agent experience with inline code lenses in editor buffers. code-lens-provider.ts parses the active GraphQL document, walks the resulting AST for operation and fragment definitions, and emits code lenses for each operation. For a Data Connect service that encloses the file, lenses such as Run (local) and a generated read query are attached, with arguments that include the parsed operation, document text, document path, and an InstanceType.LOCAL marker. Source: firebase-vscode/src/data-connect/code-lens-provider.ts:1-40

A sibling provider, ConfigureSdkCodeLensProvider, watches for connector.yaml files. When the file is part of an enclosing service and connector, it emits a single Configure Generated SDK code lens at the top of the file that, when clicked, triggers the fdc.connector.configure-sdk command. Source: firebase-vscode/src/data-connect/code-lens-provider.ts:60-85

See Also

• src/mcp/README.md – canonical description of the Firebase MCP server and its capabilities.
• scripts/agent-evals/README.md – full documentation for the agent evaluation harness.
• Top-level README.md – full list of CLI commands, including Realtime Database and Extensions commands surfaced to the same ecosystem.
• Release notes for v15.13.0–v15.19.1 – recent context that affects MCP tools (SQL Connect schema cache validation, dartfunctions flag, MCP tool input-shape fixes).

Doramagic Pitfall Log

Found 26 structured pitfall item(s), including 6 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | cevd_4f2a1ec2bb424d1686851f68154c4080 | https://github.com/firebase/firebase-tools/issues/10591

2. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | cevd_84267a150a9947d2be48a0fed4c04fba | https://github.com/firebase/firebase-tools/issues/10585

3. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: Support loose binding / aliasing for existing GCP Secrets in defineSecret
• User impact: Developers may expose sensitive permissions or credentials: Support loose binding / aliasing for existing GCP Secrets in defineSecret
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Support loose binding / aliasing for existing GCP Secrets in defineSecret. Context: Observed when using docker
• Evidence: failure_mode_cluster:github_issue | fmev_99c9e511eabefddccfad471be174c50f | https://github.com/firebase/firebase-tools/issues/10597

4. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: functions emulator: "Failed to load function" intermittent failure with no diagnostic information
• User impact: Developers may expose sensitive permissions or credentials: functions emulator: "Failed to load function" intermittent failure with no diagnostic information
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: functions emulator: "Failed to load function" intermittent failure with no diagnostic information. Context: Observed when using windows, macos, linux
• Evidence: failure_mode_cluster:github_issue | fmev_441197228e621e13cb5b731e277d1106 | https://github.com/firebase/firebase-tools/issues/10585

5. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | cevd_c546fc217e664baa87450621587fee31 | https://github.com/firebase/firebase-tools/issues/10590

6. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | cevd_6d785c6692184850a18951f28749620f | https://github.com/firebase/firebase-tools/issues/10597

7. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: [cloud functions for dart] Allow functions in a folder different than "bin" to workaround build hook issues
• User impact: Developers may fail before the first successful local run: [cloud functions for dart] Allow functions in a folder different than "bin" to workaround build hook issues
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: [cloud functions for dart] Allow functions in a folder different than "bin" to workaround build hook issues. Context: Observed when using linux
• Evidence: failure_mode_cluster:github_issue | fmev_caf934975aa33855b8941b352a3e56ef | https://github.com/firebase/firebase-tools/issues/10591

8. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v15.11.0
• User impact: Upgrade or migration may change expected behavior: v15.11.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v15.11.0. Context: Observed when using macos
• Evidence: failure_mode_cluster:github_release | fmev_f32bcea39b7c3fc39503955cd4dcec71 | https://github.com/firebase/firebase-tools/releases/tag/v15.11.0

9. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v15.12.0
• User impact: Upgrade or migration may change expected behavior: v15.12.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v15.12.0. Context: Observed during installation or first-run setup.
• Evidence: failure_mode_cluster:github_release | fmev_b1e3fdd4c3a2c14194df3ccdd059cdff | https://github.com/firebase/firebase-tools/releases/tag/v15.12.0

10. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v15.18.0
• User impact: Upgrade or migration may change expected behavior: v15.18.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v15.18.0. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | fmev_37e78bf4fc82806298e92f88c2607e5f | https://github.com/firebase/firebase-tools/releases/tag/v15.18.0

11. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Cloud Functions v1 LIST API regression — "Precondition check failed" 400 blocks ALL deploys for gen2-only projects (24h+ active)
• User impact: Developers may misconfigure credentials, environment, or host setup: Cloud Functions v1 LIST API regression — "Precondition check failed" 400 blocks ALL deploys for gen2-only projects (24h+ active)
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Cloud Functions v1 LIST API regression — "Precondition check failed" 400 blocks ALL deploys for gen2-only projects (24h+ active). Context: Observed when using python
• Evidence: failure_mode_cluster:github_issue | fmev_db6c88f426952b1deb5160d624950d65 | https://github.com/firebase/firebase-tools/issues/10590

12. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Project restored but still showing PROJECT_SOFT_DELETED - Firestore deleted, Auth broken
• User impact: Developers may misconfigure credentials, environment, or host setup: Project restored but still showing PROJECT_SOFT_DELETED - Firestore deleted, Auth broken
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Project restored but still showing PROJECT_SOFT_DELETED - Firestore deleted, Auth broken. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_issue | fmev_f7d5bb1217b384d360f1543ca266b21c | https://github.com/firebase/firebase-tools/issues/10603

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using firebase-tools with real data or production workflows.

• Project restored but still showing PROJECT_SOFT_DELETED - Firestore dele - github / github_issue
• [[cloud functions for dart] Allow functions in a folder different than "b](https://github.com/firebase/firebase-tools/issues/10591) - github / github_issue
• Cloud Functions v1 LIST API regression — "Precondition check failed" 400 - github / github_issue
• functions emulator: "Failed to load function" intermittent failure with - github / github_issue
• Support loose binding / aliasing for existing GCP Secrets in `defineSecr - github / github_issue
• v15.19.1 - github / github_release
• v15.19.0 - github / github_release
• v15.18.0 - github / github_release
• v15.17.0 - github / github_release
• v15.16.0 - github / github_release
• v15.15.0 - github / github_release
• v15.14.0 - github / github_release