This article follows the official documentation. We haven’t tested this tool for a hands-on review.
When a coding agent has shell access to a Firebase project, it can use the Firebase CLI to run the same commands a developer uses. It can inspect projects or start local emulators, and it can deploy Firebase resources. The CLI is a command-line program that connects your local code and configuration to Firebase services. Some commands only show project information; others change Firebase resources.
For example, an agent can list the Firebase projects available to your account before you ask it to make a change. The command contacts Firebase, so the agent needs an authenticated CLI session. The Firebase CLI documentation covers installation, authentication, and commands for project work.
Install and authenticate
Install the CLI with npm, the package manager for JavaScript tools:
npm install -g firebase-tools
Then sign in:
firebase login
The login command opens a browser so you can authenticate with Google. Complete that step yourself before giving an agent access to the shell. The CLI stores credentials on the machine; do not paste passwords, access tokens, or other secrets into an agent prompt.
Check that the CLI is available:
firebase --version
Firebase also describes how its CLI fits alongside agent skills and the Firebase MCP server. Skills provide Firebase-specific instructions, while the CLI runs project and environment commands; see Firebase’s AI assistance overview.
List accessible projects
A useful first task is to ask an agent which Firebase projects your signed-in account can access. Run:
firebase projects:list
The CLI sends a request to Firebase and prints a list of projects, including project identifiers. This command reads account and project information; it does not deploy code or create resources. The list reflects the credentials on the machine, so review it before asking the agent to choose a project for later commands.
A realistic prompt is:
Run
firebase projects:listand tell me which project IDs are available. Do not deploy, create, or modify any Firebase resources.
The command may fail if you have not signed in or if the signed-in account cannot access any Firebase projects. Have the project owner confirm access rather than placing credentials in the prompt.
Separate local work from cloud changes
The CLI also starts Firebase emulators, which are local versions of Firebase services for development and testing. For a project with Firebase configuration, an agent can run:
firebase emulators:start
This starts the configured emulators on the local machine. It does not deploy those services to a Firebase project. On the first run, the CLI may download emulator components and need network access, even though the emulated services run locally. Firebase’s CLI documentation describes emulator commands and project setup.
Deployment is a separate action. For example, firebase deploy publishes configured resources to Firebase. That command makes a service-side change, so ask the agent to inspect the project configuration and explain what it intends to deploy before approving a deployment. A local emulator run helps test local behavior; it does not prove that a cloud deployment is safe or correct.
Keep project selection explicit
Firebase configuration in a repository often names a default project, which commands target when you do not specify a project. Before an agent runs a command that changes cloud resources, confirm which project the repository targets. If the agent needs to select a project explicitly, Firebase CLI commands support a --project option; use the project ID you verified rather than relying on an unexplained default.
The CLI can perform both read and write operations, and the shell command itself determines which kind it performs. Listing projects and starting local emulators are suitable inspection or development tasks. Deploying resources, creating projects, and changing Firebase configuration require separate approval.