1. 多用户服务器上装 Gemini CLI为什么总在权限和 Key 上翻车一台多人共用的开发服务器最典型的场景是这样运维或者团队里第一个动手的人用sudo npm install -g google/gemini-cli把 Gemini CLI 装好了自己跑得挺顺。第二天另一个同事登录进来敲gemini直接报command not found或者命令能跑但一启动就提示找不到 API Key再或者更隐蔽——同事 A 的 Key 被同事 B 的终端继承了账单全算在 A 头上。这些问题的根子不在 Gemini CLI 本身而在 npm 全局安装的路径策略、Node.js 版本来源、以及环境变量到底写进了哪个用户的 shell 配置文件。Gemini CLI 是一个基于 Node.js 的命令行工具它依赖 npm 的全局 bin 目录能被所有用户的PATH找到同时它读取GEMINI_API_KEY和GOOGLE_GEMINI_BASE_URL这类环境变量而这些变量如果只写在某个用户的~/.bashrc里其他用户天然读不到。我试过在一台 5 人共用的 Ubuntu 机器上反复折腾这套东西踩过的坑包括用 nvm 装的 Node 导致全局包落在用户家目录、root 装的 gemini 普通用户没权限执行、以及把 Key 硬编码进系统级 profile 导致所有人共用一把 Key 无法区分调用来源。这篇就按“先解决全局可用再解决 Key 隔离”的顺序把每一步的可复制配置写清楚。核心检索词先明确Gemini CLI 是 Google 官方推出的终端 AI 编程助手能在命令行里做代码问答、文件读写、命令执行npm 是它的分发方式Node.js 是它的运行时API KEY 和环境变量决定了它连到哪个后端、用谁的身份。适合谁适合需要在共享服务器上给多个开发者统一提供 AI 编码能力、又想让每人用自己的 Key 或统一走一个受控入口的团队。下面所有操作都基于一个前提你有一台 Linux 服务器Ubuntu/Debian 系为主其他发行版命令自行替换有 root 或 sudo 权限并且已经决定用 TaoToken 作为统一的模型接入入口。TaoToken 在这里扮演的角色是提供一个兼容的 Base URL 和统一的 Key 管理让 Gemini CLI 不必直连官方、也不必每个用户各自申请一堆凭证。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 。2. 前置准备Node.js 版本、npm 全局路径与 TaoToken Key 的获取在装 Gemini CLI 之前先把运行时和路径这两件事定死否则后面多用户一定出问题。2.1 Node.js 用系统级安装别用 nvm多用户环境最大的坑就是 nvm。nvm 把 Node 装在~/.nvm下全局包也落在用户家目录root 装的普通用户用不了普通用户装的 root 又看不到。正确做法是用 NodeSource 装系统级 Node.js。以 Node 20 为例sudo su - curl -fsSL https://deb.nodesource.com/setup_20.x | bash - apt install -y nodejs node --version npm --version装完后which node应该输出/usr/bin/nodewhich npm输出/usr/bin/npm。如果输出的是/root/.nvm/...或/home/xxx/.nvm/...说明系统里还残留 nvm 的 PATH 污染需要检查/etc/profile.d/和每个用户的~/.bashrc把 nvm 相关行注释掉再重新登录。2.2 确认 npm 全局前缀是系统目录npm 的全局包默认装到$(npm config get prefix)/lib/node_modules可执行文件软链到$(npm config get prefix)/bin。系统级 Node 的默认 prefix 通常是/usr也就是 bin 在/usr/bin这个目录本来就在所有用户的 PATH 里最省事。先确认npm config get prefix如果输出/usr完美。如果输出的是某个用户家目录比如/home/alice/.npm-global说明之前有人改过配置需要改回系统级sudo npm config set prefix /usr改完后/usr/bin下的 gemini 就能被所有用户找到。这一步是多用户共享的关键务必确认。2.3 在 TaoToken 拿到统一 Key登录 TaoToken 控制台进入 API Keys 页面创建一个新的 Key。这个 Key 就是后面所有用户共用的接入凭证如果你要做按人隔离也可以每人建一个但 Base URL 是同一个。同时记下两个值Base URLhttps://taotoken.net/apiAPI Key形如sk-xxxxxxxx以控制台实际显示为准TaoToken 的模型对话页面可以用来先验证 Key 是否可用接入文档页面有各客户端的详细配置说明。建议先在网页端发一条测试消息确认 Key 有效再往下走避免把问题带到 CLI 层。2.4 规划环境变量的写入位置多用户下环境变量有两个层级系统级写在/etc/profile.d/taotoken.sh所有用户登录都生效适合放 Base URL 这种非敏感、人人相同的配置。用户级写在每个用户的~/.bashrc或~/.zshrc适合放各自的 API Key实现按人隔离。如果你团队规模小、接受共用一把 Key那 Key 也可以放系统级如果要区分调用来源就 Base URL 放系统级、Key 放用户级。下面两种写法我都会给。3. 可复制配置settings.json 与 config.toml 骨架 环境变量写入这一节是全文的核心所有片段都可以直接复制。先装 CLI再写配置。3.1 全局安装 Gemini CLI用 root 或 sudo 执行sudo npm install -g google/gemini-cli which gemini gemini --versionwhich gemini应输出/usr/bin/gemini。如果输出为空回到 2.2 检查 prefix。装完后普通用户直接敲gemini就应该能启动不需要任何额外 PATH 配置——这正是系统级安装的价值。3.2 系统级环境变量Base URL 统一写入创建/etc/profile.d/taotoken.shsudo tee /etc/profile.d/taotoken.sh /dev/null EOF # TaoToken 统一接入配置系统级所有用户生效 export GOOGLE_GEMINI_BASE_URLhttps://taotoken.net/api EOF sudo chmod 644 /etc/profile.d/taotoken.sh注意这里只放 Base URL不放 Key。/etc/profile.d/下的脚本在登录 shell 时自动 source新开的终端立即生效已开的终端需要source /etc/profile或重新登录。3.3 用户级 API Key按人隔离让每个用户在自己的~/.bashrc末尾追加echo export GEMINI_API_KEYsk-你的TaoToken密钥 ~/.bashrc source ~/.bashrc如果你要共用一把 Key就把这行也放进/etc/profile.d/taotoken.sh但要注意该文件默认权限是 644同机其他用户可读敏感 Key 不建议这么放。更稳妥的共用方式是放/etc/environment并收紧权限或者干脆每人一个 Key。3.4 Gemini CLI 的 settings.json 骨架Gemini CLI 支持通过~/.gemini/settings.json做持久化配置。多用户下每个用户有自己的家目录所以这个文件天然隔离。骨架如下{ theme: Default, selectedAuthType: gemini-api-key, apiKey: , baseUrl: https://taotoken.net/api, model: { name: gemini-2.5-pro } }字段说明selectedAuthType设为gemini-api-key表示走 API Key 认证而不是 OAuth 登录apiKey留空表示从环境变量GEMINI_API_KEY读取这样避免把 Key 写进文件baseUrl指向 TaoTokenmodel.name按你实际要用的模型 ID 填。如果你希望把 Key 直接写进文件不推荐但可行把apiKey填上即可同时记得chmod 600 ~/.gemini/settings.json。3.5 config.toml 骨架兼容 TOML 配置的客户端有些基于 Gemini 生态的工具链读 TOML 配置比如放在~/.config/gemini/config.toml。骨架[api] base_url https://taotoken.net/api api_key_env GEMINI_API_KEY [model] name gemini-2.5-pro temperature 0.7 [auth] type api_keyapi_key_env指定从哪个环境变量读 Key这样配置文件本身不含敏感信息可以安全地纳入版本管理或团队分发。base_url与系统级环境变量保持一致避免两处配置打架。3.6 三件套对照表无论用哪种配置方式接入 TaoToken 都离不开这三个值务必对齐配置项值写入位置Base URLhttps://taotoken.net/api系统级 profile 或 settings.jsonAPI Key控制台创建的sk-...用户级环境变量或 settings.jsonModel ID如gemini-2.5-prosettings.json / config.toml三件套缺一不可且 Base URL 和 Key 的来源要一致否则会出现认证通过但请求打到错误后端的情况。4. 验证请求多用户下确认 CLI 调用成功配置写完必须验证而且要分用户验证因为多用户问题的本质就是“A 能用 B 不能用”。4.1 单用户基础验证先在一个用户下确认环境变量读到了echo $GOOGLE_GEMINI_BASE_URL echo $GEMINI_API_KEY | head -c 8第一条应输出https://taotoken.net/api第二条输出 Key 的前 8 位不要完整打印避免泄露到日志。然后启动gemini首次启动会让你选择认证方式方向键选中Use Gemini API Key回车。如果环境变量已正确设置它会直接读取不再要求输入。进入交互界面后发一条解释一下当前目录下 package.json 的作用能正常返回内容说明 Base URL、Key、模型三件套全部打通。4.2 非交互式验证适合脚本和批量检查用管道传一个简单 prompt避免进入交互界面echo 用一句话说明什么是环境变量 | gemini如果返回了合理回答说明 CLI 在非交互模式下也能正常调用。这个命令很适合写进部署后的自检脚本。4.3 多用户交叉验证这是最关键的一步。切换到第二个用户su - bob which gemini gemini --version echo $GEMINI_API_KEY | head -c 8 gemini预期结果which gemini输出/usr/bin/gemini证明全局安装对所有用户可见gemini --version正常输出版本号Key 前 8 位是 bob 自己的证明隔离生效交互界面能正常问答。如果 bob 的which gemini为空问题在 npm prefix 或 PATH如果 Key 为空问题在 bob 的~/.bashrc没写或没 source如果 Key 是 alice 的说明系统级 profile 里误放了 Key需要移除。4.4 用 curl 直接验证 TaoToken 端点在排查 CLI 之前先用 curl 确认 TaoToken 端点本身可达能快速定位问题在网络层还是配置层curl -s -o /dev/null -w %{http_code}\n \ -H Authorization: Bearer $GEMINI_API_KEY \ https://taotoken.net/api返回 200 或 401 都说明网络通401 是 Key 问题200 是正常。如果连不上或超时先解决网络别在 CLI 配置上浪费时间。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth多用户环境下报错往往有迷惑性下面按真实报错逐条拆。5.1 401 Unauthorized最常见。含义是 Key 无效或没被读到。排查顺序先确认环境变量在当前 shell 里真的存在echo $GEMINI_API_KEY。如果为空检查~/.bashrc是否写了、是否 source 了、是否在正确的用户下。注意sudo gemini会切换到 root 的环境root 的~/.bashrc里没有你的 Key所以不要用 sudo 跑 gemini。如果变量存在但仍 401去 TaoToken 控制台确认 Key 没过期、没被删除、额度没耗尽。可以到模型对话页面用同一把 Key 发一条消息交叉验证。还有一种隐蔽情况settings.json 里apiKey字段填了一个旧 Key覆盖了环境变量。检查~/.gemini/settings.json把apiKey清空让它回退到环境变量。5.2 local proxy failed / connection refused这个报错通常出现在 Base URL 配错或网络不通时。检查GOOGLE_GEMINI_BASE_URL是否精确等于https://taotoken.net/api注意不要多斜杠、不要漏https、不要写成带路径的变体。用 4.4 的 curl 命令验证端点可达。如果服务器有出网限制确认能访问taotoken.net的 443 端口。5.3 reading choices / 解析响应失败这类报错说明请求发出去了、也收到了响应但响应格式不符合 CLI 预期。常见原因是 Base URL 指向了一个不兼容 Gemini 协议的后端或者模型 ID 填错导致后端返回了错误结构。确认baseUrl是 TaoToken 的 Gemini 兼容端点model.name是 TaoToken 支持的模型 ID。可以到接入文档页面核对当前支持的模型列表。5.4 OAuth 登录被意外触发如果你明明配了 API Key启动时却弹出浏览器 OAuth 登录说明selectedAuthType没生效。检查~/.gemini/settings.json里selectedAuthType是否为gemini-api-key。如果文件不存在或字段拼错CLI 会回退到默认的 OAuth 流程。多用户服务器通常没有浏览器OAuth 走不通所以这个字段必须配对。5.5 普通用户 command not found回到 2.2npm config get prefix必须是/usr或/usr/local这类系统目录。如果是用户家目录用sudo npm config set prefix /usr改回来然后重新sudo npm install -g google/gemini-cli。改完让所有用户重新登录或手动export PATH$PATH:/usr/bin临时验证。5.6 排障速查表报错最可能原因第一步动作401Key 缺失/失效/被覆盖echo $GEMINI_API_KEYlocal proxy failedBase URL 错或网络不通curl 测端点reading choices后端不兼容或模型 ID 错核对 Base URL 与模型OAuth 弹窗selectedAuthType 未生效检查 settings.jsoncommand not foundnpm prefix 非系统目录npm config get prefix排障时优先用 API Keys 页面确认凭证状态再对照接入文档核对配置字段最后用模型对话页面做端到端验证三层定位基本能覆盖九成问题。6. 长期编码与团队协作把 TaoToken 接入固定下来单次装好只是开始多用户环境真正省心的是把接入方式固化。如果你团队里有人长期用 Gemini CLI 做编码、跑 Agent 任务建议统一走 Coding Plan把额度和调用集中管理避免每人各自申请 Key 导致账单分散、权限失控。Coding Plan 页面有套餐和接入说明适合把 CLI 作为日常开发工具的团队。具体到落地我建议做三件事。第一把/etc/profile.d/taotoken.sh纳入服务器的初始化脚本或配置管理新机器一条命令铺好 Base URL。第二把~/.gemini/settings.json的骨架做成模板新成员入职时复制一份、填上自己的 Key 即可减少手抖配错。第三写一个自检脚本登录后自动跑which gemini、gemini --version、curl 测端点三步任何一步失败就提示对应排查方向。对于需要更细粒度控制的场景比如按项目区分 Key、按人统计用量可以在 TaoToken 控制台为每个项目或每个人建独立 Key然后写进各自的用户级环境变量。这样 Base URL 系统级统一、Key 用户级隔离既保证了全局可用又保留了审计能力。最后提醒一个容易忽略的点Gemini CLI 会读写当前工作目录下的文件多用户共享服务器上要注意目录权限避免 A 的 CLI 会话误改 B 的项目文件。这不是 TaoToken 或 CLI 的问题而是共享环境的基本纪律——给每个用户独立的项目目录用文件系统权限隔离CLI 层只负责把模型能力接进来。按上面这套走下来一台多用户服务器从零到所有用户都能用 Gemini CLI大概十几分钟。真正花时间的不是安装而是把路径、Key、配置三者的边界划清楚。划清楚了后面加人、换模型、调额度都是改一两行配置的事。