gemini-cli-web

Use your Gemini web subscription as the backend for the official Gemini CLI.

This exists because Google exposes two different surfaces:

• the Gemini web/app product, authenticated by browser session cookies
• the official Gemini CLI, authenticated through its own developer-facing flow

If you want the Claude Code feeling of "my web account and my CLI feel like the same thing", this repo is the bridge.

Claude Code Analogy

With Claude Code, many users experience a practical continuity between the account they use on the web and the account they use in the coding agent. It feels like one product surface with one identity.

Gemini is not shaped like that.

• Claude Code mental model: one coding product, local agent, account/session continuity
• Gemini reality: web subscription and official CLI are separate auth/billing paths

gemini-cli-web makes Gemini feel closer to the Claude Code model:

• you keep using the official local gemini CLI
• but the model backend is driven by your Gemini web cookies/session
• so your terminal agent uses your Gemini web entitlement, not AI Studio API billing

Important: this is an unofficial bridge, not a first-party shared-auth feature from Google.

How It Works

The repo does not patch Gemini CLI's OAuth flow.

It wraps the transport layer instead:

1. gemini-cli-web launches the official gemini binary
2. it points Gemini CLI at a local Gemini-API-shaped proxy
3. the proxy translates Gemini CLI requests into Gemini web requests
4. Gemini web answers using your web session cookies
5. the proxy translates the result back into the shape the official CLI expects

That means:

• local file access and tool execution still happen on your machine
• model inference happens on Gemini web
• the bridge is the thin compatibility layer in between

What You Get

• the official Gemini CLI interface
• local tool calling
• local file read/write through Gemini CLI's normal tool system
• Gemini web subscription as the model backend
• optional workspace widening with --include-directories

What You Do Not Get

• official Google support
• a stable public API contract for Gemini web internals
• native Gemini web function calling
• guaranteed long-term compatibility if Google changes the web app

Current Status

This bridge has been tested end-to-end for:

• proxy health and request translation
• tool-call envelope translation
• real file reads
• real file writes through the official Gemini CLI tool loop

The current default web mode mapping is:

• gemini-3.1-pro

That mapping is based on observed Gemini web request headers, not public API docs.

Requirements

• Node.js 20+
• the official gemini CLI installed and on PATH
• a Chrome profile you can use to sign into Gemini web
• a Gemini web subscription/account

Optional:

• an existing Gemini web cookie file from another tool, if you want to point GEMINI_WEB_AUTH_PATH at it

Install

git clone <repo-url> gemini-cli-web
cd gemini-cli-web
npm install
chmod +x bin/gemini-cli-web
npm link

This exposes:

gemini-cli-web

Authentication

The default auth file is:

~/.gemini-cli-web/auth.json

You can override it with:

export GEMINI_WEB_AUTH_PATH=/path/to/auth.json

If auth is missing or expired, the wrapper tries:

1. an optional headless refresh if you set GEMINI_WEB_HEADLESS_REFRESH_DIR to another compatible toolchain that knows how to refresh Gemini web cookies
2. an interactive Chrome login flow from this repo

The interactive flow writes the cookie file back to GEMINI_WEB_AUTH_PATH.

Usage

Basic:

gemini-cli-web -p "Reply with exactly HELLO"

Auto-approve edit tools:

gemini-cli-web --approval-mode=auto_edit -p "Read foo.txt and update bar.txt"

YOLO mode:

gemini-cli-web --approval-mode=yolo

Workspace Scope

Gemini CLI still enforces its own workspace sandbox.

This repo can widen that sandbox by injecting --include-directories.

Example:

export GEMINI_WEB_WORKSPACE_ROOT=/path/to/build
gemini-cli-web --approval-mode=auto_edit

That makes Gemini CLI's file tools usable anywhere under /path/to/build.

This is the closest practical equivalent to "let Gemini act like Claude Code over my local tree":

• the model can request reads and writes
• the official CLI executes them locally
• the workspace boundary is explicit and controllable

Environment Variables

• GEMINI_WEB_PROXY_MODEL Default: gemini-3.1-pro
• GEMINI_WEB_PROXY_HOST Default: 127.0.0.1
• GEMINI_WEB_PROXY_PORT Default: 4319
• GEMINI_WEB_AUTH_PATH Cookie store path
• GEMINI_WEB_CHROME_USER_DATA Chrome profile root for interactive login
• GEMINI_WEB_WORKSPACE_ROOT Directory to inject via --include-directories
• GEMINI_WEB_HEADLESS_REFRESH_DIR Optional directory where npm run auth can refresh cookies before falling back to interactive login
• GEMINI_WEB_CLI_LOG_DIR Proxy logs and pid files

Testing

Unit tests:

npm test

Real smoke test:

gemini-cli-web --approval-mode=auto_edit -p "Read a file and write another one"

Architecture Notes

The proxy emulates the Gemini Developer API endpoints Gemini CLI expects:

• :generateContent
• :streamGenerateContent?alt=sse
• :countTokens

Tool calling is adapted by prompt protocol:

• Gemini CLI sends tool declarations
• the proxy renders them into a structured prompt for Gemini web
• Gemini web returns either:
  • {\"type\":\"text\", ...}
  • {\"type\":\"tool_calls\", ...}
• the proxy converts that back into Gemini API functionCall parts

So tool calling works, but it is a compatibility layer rather than native web-side function calling.

Limitations

• fragile against Gemini web frontend changes
• model selection is based on observed web hashes
• countTokens is approximate
• the bridge depends on Gemini CLI behavior and Gemini web behavior staying similar enough

Why This Repo Exists

The narrow goal is simple:

Make Gemini feel like Claude Code does when your real entitlement is the web product.

Not by pretending Google unified the products.

By building the missing bridge.