# A local cloud for AI coding agents

> Code sandboxes isolate where an AI agent runs. LocalCloud gives that code local Google Cloud APIs on localhost, with no credentials or billing by default.
>
> Source: https://local.cloud/local-cloud-for-ai-agents/

Agent environment · dependency boundary

A code sandbox isolates _where_ an AI agent runs. It does not change _what_ the agent's code calls. LocalCloud supplies that missing half: Google Cloud APIs answered on localhost, so agent-written cloud code executes with no credentials, no billing project, and no real cloud side effects.

[Start in the docs](https://local.cloud/docs/) [Agent resources](https://local.cloud/ai/) [Compare with hosted sandboxes](https://local.cloud/compare/e2b-vercel-sandboxes/)

25

Local services

Google Cloud APIs an agent can call without leaving the machine.

0

Credentials by default

No service-account key or billing project is required for documented local workflows.

1

Command to start

One CLI lifecycle, one health endpoint, one generated environment export.

The distinction that matters

## An agent environment has two boundaries

Most agent tooling addresses only the first one. Cloud cost and cloud blast radius live in the second.

Execution boundary

### Where the generated code runs

Owned by a code sandbox. Containers, microVMs, or a hosted runtime keep an agent from touching your workstation, your repository, or your production hosts.

Typically owned by: E2B, Docker Sandboxes

Dependency boundary

### What the generated code calls

Owned by a local cloud runtime. Google Cloud SDK calls resolve to localhost instead of googleapis.com, so an agent cannot create real cloud resources or real charges.

Typically owned by: LocalCloud

> **A sandbox with real credentials is still a real cloud client**
>
> Isolating execution does not stop an API call. If a code sandbox holds a service-account key, agent-written code can create datasets, buckets, and instances in your project from inside that sandbox, and the charges are real. Closing the dependency boundary is a separate control.

Honest comparison

## Where each tool is the right answer

LocalCloud is not a replacement for a code sandbox, and a code sandbox is not a replacement for a local cloud. Pick by which boundary you are trying to close.

| What you need | Code sandbox | LocalCloud |
| --- | --- | --- |
| Contain arbitrary generated shell and code execution | Primary purpose. Use a code sandbox. | Not the isolation layer for arbitrary shell risk. |
| Stop an agent from creating billable Google Cloud resources | Not addressed. A sandbox holding real credentials still reaches the real cloud. | Primary purpose. No default credentials or billing project. |
| Exercise BigQuery, Pub/Sub, Spanner, or Bigtable behavior | Requires real Google Cloud access from inside the sandbox. | Local endpoints for 25 local services. |
| Run an AWS-shaped local cloud | Not applicable. | Not supported. LocalStack is the right tool for AWS. |
| Give a coding agent a repeatable, inspectable local target | Varies by provider. | Health endpoint, generated env export, seed data, and a web console. |

[LocalCloud vs hosted sandboxes](https://local.cloud/compare/e2b-vercel-sandboxes/) [LocalStack for Google Cloud](https://local.cloud/localstack-for-google-cloud/) [LocalCloud vs Google emulators](https://local.cloud/compare/google-emulators/)

Setup

## Give an agent a local cloud target

Start the runtime, load its generated environment values into the agent's shell, and let the standard Google Cloud SDKs resolve to localhost.

Host CLI quick start

```
curl -fsSL https://local.cloud/install.sh | sh
localcloud doctor
localcloud start --local-only
curl -fsS http://localhost:5380/readiness
eval "$(localcloud env)"
localcloud console
```

Trust the URLs and values the CLI returns. If a default port is already in use, the CLI picks another one, so read the generated environment rather than assuming a fixed port. Homebrew users can install with `brew install LocalGCloud/tap/localcloud`.

Agent instructions

### Machine-readable setup

LocalCloud publishes a raw [AGENTS.md template](https://local.cloud/ai/agent-template.md) and Markdown route index that agents can read directly, without parsing marketing HTML.

Per-agent guides

### Setup by coding agent

- [Claude Code](https://local.cloud/agents/claude-code-gcp-sandbox/)
- [Codex CLI](https://local.cloud/agents/codex-cli-gcp-sandbox/)
- [Cursor](https://local.cloud/agents/cursor-gcp-sandbox/)
- [Gemini CLI](https://local.cloud/agents/gemini-cli-gcp-sandbox/)

Boundaries

## What this does not give you

- Use only local endpoint values. If a step would need real Google Cloud or real credentials, stop. The Public Preview License permits individuals and organizations, including for-profit companies, to use LocalCloud for non-production internal development, testing, CI, evaluation, and pilots.
- LocalCloud runs local versions of Google Cloud services for development and testing. Validate application behavior against real Google Cloud before production deployment.
- Before production deployment, unset LocalCloud emulator environment variables and validate behavior against real Google Cloud.

LocalCloud does not isolate arbitrary code execution. If an agent runs untrusted shell commands, pair it with a code sandbox. Review the [compatibility matrix](https://local.cloud/compatibility/) for per-operation status and the [licensing reference](https://local.cloud/docs/licensing/) for permitted use.

FAQ

## Agent environment questions

### What is an agent environment?

An agent environment is everything an AI coding agent can reach while working: where its code executes and what that code is allowed to call. A code sandbox owns the execution half. A local cloud runtime such as LocalCloud owns the dependency half by answering cloud SDK calls on localhost.

### Is a code sandbox enough to keep an AI agent from touching my cloud account?

No. A sandbox isolates where code runs, not what it calls. If the sandbox holds Google Cloud credentials, agent-written code can still create real resources and real charges from inside it. Removing credentials and pointing the SDKs at a local runtime closes that gap.

### How do I give an AI agent a cloud to test against without credentials?

Start LocalCloud, load its generated environment values into the agent process, and let the standard Google Cloud SDKs resolve to localhost. No cloud project, service-account key, or billing account is required by default for the documented local workflows.

### Does LocalCloud replace E2B or Docker Sandboxes?

No, and it is not trying to. Those products isolate arbitrary code execution, which LocalCloud does not do. They are complementary: run the agent inside a code sandbox and point its Google Cloud calls at LocalCloud.

### Can an AI agent write code against LocalCloud and then ship it to real Google Cloud?

Local runs are a development and testing step, not a release gate. Compatibility is documented per operation and is narrower than managed Google Cloud, so validate the same code against real Google Cloud in a separate guarded step before production.

### Which coding agents work with LocalCloud?

Any agent that can run shell commands and read environment variables. LocalCloud publishes setup pages for Claude Code, Codex-style CLIs, Cursor, and Gemini CLI, plus a raw AGENTS.md template agents can read directly.

Keep reading

## Related pages

- [Agent setup guides](https://local.cloud/agents/): Setup pages for Claude Code, Codex CLI, Cursor, and Gemini CLI.
- [Agent workflows](https://local.cloud/workflows/): Integration tests, Terraform validation, and automation with health gates.
- [Glossary: AI agent sandbox](https://local.cloud/glossary/ai-agent-sandbox/): Definitions for the execution and dependency boundaries.