Agent environment / gemini-cli

Run Gemini CLI in an isolated cloud sandbox.

One API call gives Gemini CLI a real Linux machine with a full checkout of your repository — its million-token context window pointed at real files, not pasted snippets.

Start building Quickstart

TEMPLATE

gemini-cli

AUTH

GEMINI_API_KEY

ISOLATION

gVisor

EGRESS

default-deny

OVRIN / SANDBOX 5E77 EXITED 0

import ovrin client = ovrin.Client() sandbox = client.sandboxes.create( template="gemini-cli", env={"GEMINI_API_KEY": key}, ) result = sandbox.run( 'gemini "summarise this codebase and flag risky modules"' ) print(result.stdout)

✓isolated with gVisor19 ms

✓sandbox ready · /workspace mounted151 ms

✓Gemini CLI started2.0 s

✓task completed27.4 s

Why a sandbox

Gemini CLI is happiest with a whole machine.

Gemini CLI's advantage is context — it wants the whole repository, not a curated slice. That means it also wants filesystem and shell access wide enough to walk the whole tree, which is exactly the access you don't want unsandboxed.

01

Whole-repo context, safely

Give it the full checkout — vendored dependencies, generated files, build artifacts — without extending trust to your real infrastructure.

02

Long-context reads, short-lived sandboxes

Spin one up for a single architecture review or migration audit, then throw it away.

03

Network on a leash

Default-deny egress. Allowlist generativelanguage.googleapis.com, your registry and your git host. Nothing else resolves.

What's in the template