Google Cloud CLI for coding agents

When a coding agent has shell access to a developer’s machine, it can run the Google Cloud CLI, gcloud, to inspect Google Cloud projects and call supported cloud services. A Google Cloud project groups cloud resources and controls who can access them. The project ID tells a command which project to use.

For a read-only task, an agent can retrieve project metadata with gcloud projects describe. Include the project and account in each command so the CLI does not use different saved defaults. The Google Cloud CLI documentation covers the CLI and its command groups.

Install and authenticate

Install the CLI using the official platform-specific instructions, then run gcloud init in a terminal to configure it. Initialization and authentication contact Google Cloud, and the CLI may open a browser for sign-in.

For a local human account, gcloud auth login authenticates the CLI. Run gcloud auth list to see which accounts the CLI knows about. Commands then use the permissions Google Cloud grants to that account. An agent that can run gcloud in the same environment can use those credentials, so do not paste passwords, tokens, or key files into the agent prompt.

Google Cloud also has Application Default Credentials (ADC), a separate credential mechanism used by software libraries. For local development, the Cloud Run documentation describes gcloud auth application-default login; that command does not replace gcloud auth login for CLI commands. Use the credential method that matches what the agent will run.

Pin the project and account

The CLI saves settings on your machine, including a default project and account. Explicit --project and --account flags make the target clear for each command and override those defaults. Use a real project ID and the exact account email shown by gcloud auth list in place of the placeholders below.

gcloud auth list

gcloud projects describe PROJECT_ID \
  --project=PROJECT_ID \
  --account=ACCOUNT_EMAIL \
  --format=json

The projects describe command retrieves metadata for the named project. The command reference documents its arguments and flags. --format=json asks the CLI to print the result as JSON, which an agent can parse; the command does not change project resources. The request does contact Google Cloud, and the account needs permission to view the project. The fields and values in the JSON depend on the project, so do not treat them as fixed.

Keep inspection separate from changes

gcloud config set project PROJECT_ID changes the CLI’s local default configuration. It does not change a cloud resource, but it affects later commands that omit a project flag. Include --project in each command instead of relying on the saved default. The same principle applies to --account.

A command that creates, updates, or deletes a resource sends a write request to Google Cloud. Before the agent runs a write command, check its official reference for a preview or validation option. Do not assume that every gcloud command supports --dry-run; the read-only projects describe example above needs no preview because it only fetches metadata.

Google’s Cloud Developer plugin packages skills and tools for supported coding agents, including guidance for gcloud operations. It is separate from the CLI itself: an agent can run gcloud directly from a shell, while the plugin adds agent-oriented context and integrations.

Give the agent a bounded task

A realistic prompt for the example is:

Use gcloud to inspect the project metadata for PROJECT_ID. Use account ACCOUNT_EMAIL and pass both --project and --account on the command. Return the project ID, name, and lifecycle state from the JSON output. Do not change configuration or cloud resources.

This directs the agent to make one network read and keeps local configuration and cloud resources untouched. This article draws on documentation; it does not describe an installation or CLI test. For other command-line tools that agents can use, see the CLI directory.