Gemini CLI
Sign Gemini CLI in with your Google account or a Gemini API key, and what it uses in your terminals, in guests' shells and on your cloud boxes.
Gemini CLI signs in with your Google account by default. A Gemini API key works
too. taiku uses the login gemini already has.
Sign in with your Google account
On your own computer, run gemini and choose Sign in with Google when it
asks how to authenticate. It opens the Google sign-in page and saves the login.
A gemini you start in a taiku terminal uses that login, the same as in any
other terminal.
Use an API key instead
- Keep the key in Gemini's own settings. Put
GEMINI_API_KEY=<your key>in~/.gemini/.envand choose Use Gemini API Key ingemini. Gemini reads that file only in a folder you have trusted, so the first time you use a folder, rungeminithere and trust it. This is the way that also works fromtaiku agent --local gemini. - Export the key in your shell startup file. Put
export GEMINI_API_KEY=...in~/.zshrcor~/.bashrc. taiku's shells run that file, so the key is there. A key you only exported in the terminal you started taiku from is not passed on. taiku keeps it out oftaiku agent --local, so an agent there never answers on an account you did not pick for it. It also stays out of a guest's sandboxed shell in the defaultisolatedmode, which does not run your startup files; atrustedsandboxed shell or one without the sandbox runs them, and gets the key.
Run it from taiku agent
taiku agent --local geminiThis runs gemini on this machine with its own saved login, inside taiku's
sandbox. An exported GEMINI_API_KEY is ignored here; keep the key in
~/.gemini/.env instead, and trust the folder first.
Guests in your session
What a guest's shell gets from you depends on how it runs. Every sandboxed shell
the app opens for a guest on macOS or Linux runs in isolated mode.
| A guest's shell | Keys your startup files export | Your Gemini login |
|---|---|---|
Sandboxed, isolated | No | No, whatever --agent-credentials says |
Sandboxed, trusted (not offered in the app) | Yes | No, whatever --agent-credentials says: taiku never hands a sandboxed shell your ~/.gemini |
| Without the sandbox: Ignore sandboxing, a session whose default is no sandbox, or a Windows host | Yes | The shell runs as you and can read it. --agent-credentials decides which login gemini starts on: yours with own-or-host for guests who have not signed in, and with host for everyone |
With the default, own, a signed-in guest runs gemini on their own login,
kept in a folder of theirs on your machine, and a guest who has not signed in
gets no agent. See
Guests use their own agent logins
and Guests on your machine.
On a cloud box
Gemini is not set up on a box for you. Boxes do not come with gemini
installed, and taiku cloud does not copy your Gemini login. On the box:
sudo npm install -g @google/gemini-cli
geminiThen choose Sign in with Google. For a key instead, taiku cloud copies
your shell startup files (~/.zshrc, ~/.bashrc and the like) to a Linux box
when it opens a session there, the first time and again whenever they change, so
a GEMINI_API_KEY exported in them reaches the box's shells.
Hosted agents
The agents you keep on your account do not use your Google login. They call the model with an API key: the one this taiku holds, or your own under Settings → Agent → Model providers.