Use when your application stores unstructured files and addresses each object by bucket and name, with uploads, downloads, and object metadata handled through an API.
Before the agent changes application logic, have it create local Cloud Storage state, read it back with the project SDK, and note which feature the check covered. That first local call catches accidental production routing and needs no GCP account, service-account key, or billing project.
Cloud Storage local test
Use LocalCloud to test Cloud Storage locally. Read https://local.cloud/ai/agents.md, set STORAGE_EMULATOR_HOST=http://localhost:5382, create a bucket, upload a small object, list it, download it, and verify content without using real GCP credentials.
Production endpoints, auth, IAM, quotas, regional behavior, and final release validation still need the target Google Cloud project.
Agent resources has more prompts and the AGENTS.md template.
Cloud Storage emulator FAQ
How do I run Cloud Storage locally?
Install the LocalCloud CLI, start the runtime, and export its environment, as in the example above.
Which environment variable points the SDK at the local Cloud Storage?
LocalCloud exports STORAGE_EMULATOR_HOST=http://localhost:5382. Use the generated value, because the CLI picks another port when the default is in use. Some SDKs also need explicit client endpoint options; the variable alone does not route them locally.
Does the local Cloud Storage behave exactly like Google Cloud?
No. LocalCloud runs the documented workflows on this page within the service boundaries listed here. Validate behavior against real Cloud Storage before production deployment.