Run Gemini CLI in Docker: why it stops at folder trust, how it logs in without a browser, and where YOLO mode is safe

You want Gemini CLI to work on a repository while you do something else. You do not want it running on your laptop with every tool approved, so you put it in a Docker container. The first run with --approval-mode=yolo prints that YOLO mode is enabled, then that the approval mode was put back to default, and then it exits:

Gemini CLI is not running in a trusted directory. To proceed, either use
`--skip-trust`, set the `GEMINI_CLI_TRUST_WORKSPACE=true` environment
variable, or trust this directory in interactive mode.

Fix that and run it again with your Google login, and you may get a second refusal: Manual authorization is required but the current session is non-interactive.

Neither of these is a bug. They are two checks that Gemini CLI makes on purpose, and inside a container both of them get in the way. This post explains what each check protects, how to pass it on purpose, and when it is fine to let the agent approve its own tool calls. We ran the commands below against Gemini CLI 0.65.0 in a node:22 container.

A small image to start from

Gemini CLI is an npm package that needs Node.js 20 or newer, according to the installation docs. A plain image is enough:

FROM node:22-bookworm
RUN npm install -g @google/gemini-cli \
 && mkdir -p /home/node/.gemini && chown node:node /home/node/.gemini
USER node
WORKDIR /workspace

Build it with docker build -t gemini-box . and check it with docker run --rm gemini-box gemini --version. Running as the node user matters later. Files the agent writes into your mounted folder will belong to that user and not to root.

The agent can still do anything the node user can do inside the container. It can change the mounted folder and reach the network. The container decides what it cannot reach: your home directory, your SSH keys, other projects. Mount only the repository you want it to touch.

Check one: folder trust

Gemini CLI keeps a list of trusted folders. The trusted folders docs say what changes in a folder that is not on the list:

• Settings in the project's .gemini/settings.json are ignored.
• The project's .env files are not loaded.
• Automatic tool acceptance is turned off, so you are asked before every tool call.
• MCP servers configured for the project do not connect.
• Custom commands from the project are not loaded.

A repository you just cloned can ship a settings file that starts an MCP server or a .env that changes how the agent behaves. Trust is your statement that you read the project and accept its configuration.

On your laptop Gemini CLI asks once, in a dialog. In a container there is often no terminal to show the dialog. With -p the run is headless, so the CLI refuses and exits. That is the error at the top. We saw exit code 55 in our test.

There are two documented ways through, and both are listed in the error message: the --skip-trust flag, or GEMINI_CLI_TRUST_WORKSPACE=true in the environment. Use them for the folder you mount, and only for code you would trust on your own machine. Passing either one for a stranger's repository loads that repository's settings and MCP servers, which is exactly what the check was guarding against.

docker run --rm \
  -v "$PWD":/workspace \
  -e GEMINI_API_KEY \
  -e GEMINI_CLI_TRUST_WORKSPACE=true \
  gemini-box gemini -p "Run the tests and fix the first failure" --approval-mode=yolo

Check two: logging in without a browser

Google's authentication docs list three ways to log in: Google login in the browser, a Gemini API key, or Vertex AI. They recommend the browser login for local interactive use and an API key for headless use.

The browser login needs a browser. In a container without one, or with NO_BROWSER=true, Gemini CLI can show a link and wait for a code, but only in an interactive terminal. In a headless run it stops with the Manual authorization is required error, which you can find in the OAuth source. The same message suggests the ways out: log in interactively, set GEMINI_API_KEY, or use Application Default Credentials.

So you have two practical choices.

An API key from Google AI Studio is the simplest. Pass it with -e GEMINI_API_KEY, as in the example above, so it stays out of the image and out of your shell history. Usage then counts against that key's quota and billing.

Your Google login also works headless if it is already cached. The authentication docs say headless mode uses cached credentials when they exist. Log in once on your own machine, then mount the folder that holds them:

docker run --rm \
  -v "$PWD":/workspace \
  -v "$HOME/.gemini":/home/node/.gemini \
  -e GEMINI_CLI_TRUST_WORKSPACE=true \
  gemini-box gemini -p "Explain what this repository does"

Think about what that mount gives the agent. ~/.gemini holds your login token, your user settings and other state the CLI keeps, and the agent can read all of it. Gemini CLI also refreshes the token in that file while it works, so it needs write access. If the agent should not see your Google token, give it a separate API key instead. Our post on keeping secrets away from your coding agent covers the wider version of this question.

YOLO mode, and which sandbox does the work

With trust and login sorted, --approval-mode=yolo approves every tool call. The CLI reference lists the modes as default, auto_edit, yolo and plan, and marks the older --yolo flag as deprecated. The configuration reference says YOLO cannot be set as the default in settings.json; you pass it on the command line each time.

Gemini CLI also has its own sandbox. The sandbox docs describe --sandbox (or GEMINI_SANDBOX=docker), which runs the tools in a Docker or Podman container with your project mounted at the same absolute path. That is a good fit when Gemini CLI runs on your machine and you want only the tools boxed in.

If you already run the whole CLI in your own container, as above, --sandbox would need Docker available from inside that container. For most setups one boundary is enough. Pick the one you understand and can inspect. When your own container is the boundary, YOLO mode inside it is a reasonable choice, because the worst a tool call can do is damage the container and the folder you mounted. Keep that folder in git and push before you start, so a bad turn costs you a git reset and nothing more.

The same reasoning applies to other agents. We went through it for Codex in Run Codex CLI in Docker, and the trade-offs are close.

What Sessionboxer does here

Sessionboxer runs each session in its own Docker container, as described on one box per session. Gemini CLI is one of the agents it can start there. As agents that don't ask explains, the agent runs with all permissions granted inside the box, because the container is the boundary. You do not pass trust flags or approval modes yourself.

Login works the way the connect your agent chapter describes. You run gemini once on your own machine, choose Login with Google, then paste or import ~/.gemini/oauth_creds.json in Settings. A Gemini API key works in the same field. Vertex AI credentials do not. There is no Sign in button in Sessionboxer for Gemini CLI, because its login only happens in its own interactive screen. Tokens are handed only to the containers of sessions that use that agent and are never stored in snapshots. Because it is your own subscription, usage counts against your Google plan or your key.

Gemini CLI runs in the Docker Linux sessions and in the QEMU Windows and macOS sessions. To try it, follow start a session and pick Gemini CLI in the Agent list.

If you prefer the plain Docker route, the Dockerfile above, one trust variable and an API key are all you need. Decide which folder the agent can see before you approve every tool.