Gemini CLI sandbox-flag footgun

If you installed Gemini CLI, ran thedistillery start, saw the auto-injection log line confirm GOOGLE_GEMINI_BASE_URL was set, and then ran gemini only to find zero sessions in the dashboard — you have hit Gemini CLI's sandbox-flag footgun. This page explains what is happening, why it is silent, and the one-flag fix.

What it looks like

The symptom is a quiet bypass: nothing fails, nothing warns, and gemini returns model output as expected. The only signal is that your Distillery dashboard at http://127.0.0.1:3080 stays empty. thedistillery start confirms in its startup log that GOOGLE_GEMINI_BASE_URL → http://127.0.0.1:3080/gemini (shell profile) was written, and echo $GOOGLE_GEMINI_BASE_URL from your shell prints the proxy URL — so on the surface the env var is set. But every request still hits Google directly, and you pay full token price.

Why it happens

gemini runs in sandbox mode by default. The sandbox isolates the model process from your host environment for security, and as part of that isolation it does not propagate host environment variables into the sandboxed child — not even an allowlist. GOOGLE_GEMINI_BASE_URL, which thedistillery start writes to your shell profile, exists in your interactive shell but never crosses into the sandbox where the actual model call is made. The model client inside the sandbox falls back to its hardcoded default of generativelanguage.googleapis.com, so requests bypass The Distillery entirely.

Crucially, neither tool tells you. thedistillery start cannot inspect what happens inside Gemini's sandbox, and gemini has no awareness that you wanted requests routed elsewhere. There is no error, no warning, no log line — only an empty dashboard.

The fix

Run Gemini CLI with the sandbox disabled:

gemini --sandbox=false

With the sandbox off, your host env vars (including GOOGLE_GEMINI_BASE_URL) propagate to the model process and requests route through The Distillery as expected. You can also persist this by adding sandbox: false to your Gemini config file so you do not have to pass the flag every time. After applying the change, restart thedistillery start to confirm the runtime warning line appears, then run a quick test prompt — it should show up in the dashboard within a few seconds and be attributed to the gemini provider.

Note that disabling the sandbox is a security trade-off you make consciously. The Distillery's local-only loopback model means the proxy itself does not introduce new network exposure, but you are giving the Gemini model process direct host access. If that trade-off is unacceptable for your environment, the alternative is to skip Gemini CLI for now and route through another OpenAI-compatible client instead.

Upstream tracking

The Gemini CLI team is tracking allowlisted env-var propagation in google-gemini/gemini-cli#2168. If that lands, --sandbox=false will no longer be required and we will update this page along with the runtime warning in thedistillery start. Until then, the flag is the only known workaround.