1. 非交互模式下工具调用为什么会卡住Gemini CLI 的非交互模式-p/--prompt是给脚本和 CI/CD 用的一条命令进去结果出来中间不需要人坐在终端前点确认。但很多人第一次把它塞进流水线就会撞上一个很别扭的现象——模型明明识别出要执行ls或git status进程却直接报错退出日志里写着requires user confirmation, which is not supported in non-interactive mode。这个报错的根源不在模型而在权限链路。交互模式下工具调用走到「需要确认」这一步会弹一个提示你按 y 就过了非交互模式没有这个交互通道调度器一旦发现某个工具调用不在自动批准范围内只能抛错终止。所以你要做的不是「让模型别调工具」而是提前把哪些工具、哪些命令允许自动执行写清楚。整条链路大致是这样你传入 prompt →runNonInteractive()处理输入斜杠命令、引用→ 把消息发给模型 → 监听事件流遇到ToolCallRequest就收集起来 → 交给CoreToolScheduler调度 → 调度器调用isAutoApproved()做权限判断 → 通过就执行不通过且是非交互模式就报错 → 执行结果转成FunctionResponse回传给模型 → 进入下一轮直到没有新的工具调用为止。这里有个关键点非交互模式是支持多轮工具调用的模型可以先ls看目录再根据结果决定cat哪个文件再写文件全程自动。前提是每一步的工具调用都能通过权限检查。所以权限配置不是「开个开关」而是决定这条自动化链路能走多远的地基。我试过在 CI 里跑一个「检查代码风格并生成报告」的任务一开始用默认模式模型第一步想跑git diff就被拦了整个 job 失败。后来把允许列表配好同样的 prompt 一次跑通中间触发了四次工具调用没有任何人工干预。这篇就把这套配置和验证方法完整拆开讲包括用 TaoToken 统一 Key 接入的方式让你在批处理场景里能直接复制。适合谁看正在把 Gemini CLI 往 CI/CD、定时任务、批处理脚本里塞的工程师想让模型自动读写文件、跑命令但又不放心全放开的人以及需要一套统一 Key 管理多个 CLI 工具的团队。2. TaoToken 统一 Key 的前置准备在讲权限配置之前得先把「模型怎么连」这件事定下来。Gemini CLI 默认走官方端点但在团队协作和自动化场景里用一套统一的 Key 管理会更省心——尤其是你同时还在用别的 CLI 工具时不用每个工具单独维护一份凭证。TaoToken 在这里的角色是提供一个统一的接入层一个 Key一个 Base URL多个 CLI 工具共用。对 Gemini CLI 来说你只需要把端点指向它然后在环境变量里放好 Key 就行。先拿 Key。打开控制台创建https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole创建完在 API Keys 页面复制出来https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keysBase URL 用这个注意 API 地址不带 UTM 参数https://taotoken.net/api然后设置环境变量。Gemini CLI 读取的是GEMINI_API_KEY同时你需要告诉它走自定义端点。不同版本对端点变量的命名略有差异常见的是GOOGLE_GEMINI_BASE_URL或通过配置文件指定。稳妥的做法是环境变量和配置文件双写export GEMINI_API_KEYsk-你的TaoToken密钥 export GOOGLE_GEMINI_BASE_URLhttps://taotoken.net/api如果你在 CI 里用把这两行放进 job 的 env 段或者用 secrets 注入。注意别把 Key 硬编码进脚本提交到仓库这是最常见的翻车点。模型 ID 这块Gemini CLI 默认会用gemini-2.0之类的标识你也可以在命令里用--model显式指定。用 TaoToken 的时候模型 ID 按平台文档里列出的写别自己拼。三件套对齐一下避免后面配置时混淆项目值Base URLhttps://taotoken.net/apiAPI Key控制台创建的sk-开头密钥Model ID按平台文档如gemini-2.0系列配好之后先做个最小验证确认连通性没问题再往下折腾权限。这一步别跳过否则后面报错你分不清是权限问题还是连不上。gemini -p 回复一句话连接正常 --model gemini-2.0如果这一步就报 401 或者连接失败先解决接入问题权限配置放到后面。接入文档在这里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc3. 可复制的权限白名单配置权限控制的核心在配置文件里。Gemini CLI 读的是~/.gemini/config.toml项目级可以放.gemini/config.toml工具权限写在[tools]段。另外还有一个settings.json层面的配置用于更细粒度的控制。下面给一份可以直接抄的配置。先看config.toml的工具段。这里定义哪些工具、哪些命令允许自动执行# ~/.gemini/config.toml [general] approval_mode default # 默认模式靠允许列表放行也可设 yolo / auto_edit [tools] # 允许的核心工具只放你确实需要的 core_tools [ run_shell_command(git), run_shell_command(ls), run_shell_command(cat), run_shell_command(grep), read_file, write_to_file, search_files ] # 明确排除的危险操作优先级最高 exclude_tools [ run_shell_command(rm), run_shell_command(del), run_shell_command(format), run_shell_command(curl), run_shell_command(wget) ]这里有几个语法要点配错了会静默失效run_shell_command(git)表示只允许git这个命令git status、git diff都能过但git push --force这种也会被放行——因为匹配的是命令名不是完整参数。如果你想更严可以写run_shell_command(git status)只允许特定子命令。read_file(*)里的*是路径通配read_file(/path/to/dir/*)表示只允许读某个目录下的文件。生产环境建议把写操作限制在特定目录别用write_to_file(*)全放开。exclude_tools的优先级高于core_tools。也就是说即使你在core_tools里写了run_shell_command允许所有 shell只要exclude_tools里有run_shell_command(rm)rm依然会被拦。这个顺序是黑名单 → 通配符 → 允许列表。再看settings.json层面的配置。这个文件通常放在~/.gemini/settings.json用于控制 CLI 行为{ approvalMode: default, tools: { allowed: [ run_shell_command(git), run_shell_command(ls), run_shell_command(cat), read_file, write_to_file, search_files ], excluded: [ run_shell_command(rm), run_shell_command(del), run_shell_command(curl) ] }, logging: { toolCalls: true, logLevel: info } }注意settings.json和config.toml的字段名不完全一样别混用。approvalMode是驼峰config.toml里是下划线approval_mode。这是很多人配了半天不生效的原因——文件放对了字段名写错了。三种审批模式的区别用表格对照一下模式行为适用场景default不在允许列表的工具调用直接报错生产 CI权限收紧auto_edit自动批准文件编辑类操作代码生成、批量改写yolo全部自动批准不检查本地开发调试别上生产yolo模式在命令行里可以用-y或--approval-modeyolo临时开启但强烈建议只在本地沙箱用。CI 里用yolo等于把整个 shell 交给模型一个 prompt 注入就能删库。开启工具调用日志方便排查。在settings.json里加logging.toolCalls: true或者在命令行加--debug看详细事件流。日志会记录每次工具调用的名称、参数、权限判断结果出问题时对着日志看是哪一步被拦的。配置改完记得重启 CLI 进程环境变量和配置文件都是启动时读取的热改不生效。4. 验证一次非交互工具调用配置写好了得跑一次真实的非交互工具调用来验证。下面这个例子让模型先列目录、再读一个文件、最后输出内容全程自动不弹任何确认。先准备一个测试目录mkdir -p /tmp/gemini-test cd /tmp/gemini-test echo hello from test file sample.txt echo another line sample.txt然后跑非交互命令gemini -p 列出当前目录的文件然后读取 sample.txt 的内容并原样输出 \ --approval-modedefault \ --outputjson预期行为是这样的模型收到 prompt 后先发起run_shell_command(ls)调度器检查允许列表ls在core_tools里自动批准执行返回文件列表。模型看到有sample.txt发起read_file(sample.txt)read_file在允许列表里自动批准读取内容。模型拿到内容后直接输出文本没有新的工具调用循环结束。用--outputjson的话你能看到结构化的输出里面包含工具调用的记录。如果只想看文本结果去掉这个参数就行。再验证一个「应该被拦」的场景确认权限真的生效gemini -p 删除当前目录下的所有文件 --approval-modedefault因为rm在exclude_tools里模型即使发起了run_shell_command(rm ...)调度器也会判定不通过非交互模式下直接抛错退出返回非零退出码。你在 CI 里就能靠这个退出码判断任务是否被安全拦截。如果想看工具调用的详细过程加--debuggemini -p 读取 sample.txt 并统计行数 --debug 21 | tee gemini-debug.log日志里会看到类似ToolCallRequest: read_file、isAutoApproved: true、Executing tool这样的行。对着日志你能确认每一步的权限判断结果出问题时定位很快。流式输出场景用--outputstream-json适合你在脚本里逐事件解析gemini -p 列出文件并读取 sample.txt --outputstream-json每个事件是一行 JSON包含type字段content是文本tool_use是工具调用开始tool_result是执行结果。你的脚本可以按type分流处理。跑通之后把这条命令原样搬进 CI 的 job 里就行。记得把GEMINI_API_KEY和GOOGLE_GEMINI_BASE_URL通过 secrets 注入别写死在脚本里。5. 常见报错与排查配权限的过程中报错基本集中在几个固定位置。下面按真实遇到的顺序列出来对照着查。报错一Tool execution for run_shell_command requires user confirmation, which is not supported in non-interactive mode.这是最典型的。含义是某个工具调用没通过isAutoApproved()而当前是非交互模式没法弹确认只能报错。排查步骤先看日志里是哪个工具被拦了然后检查这个工具是否在core_tools或allowed列表里。如果是 shell 命令检查命令名是否匹配允许列表的写法——run_shell_command(git)只放行git你跑的是npm就不会过。另外确认approval_mode不是被设成了某个限制性模式。报错二401 Unauthorized或API key not valid这是接入层的问题不是权限问题。检查GEMINI_API_KEY是否设置正确有没有多余空格或换行。检查GOOGLE_GEMINI_BASE_URL是否指向https://taotoken.net/api。如果 Key 是从控制台复制的确认没复制到前后空白。CI 里用 secrets 的话确认 secret 名称和引用一致。报错三local proxy failed或连接超时通常是端点地址写错或者网络环境有问题。确认 Base URL 拼写正确没有多余的路径段。如果你在受限网络环境里检查是否能正常访问该端点。这类问题跟权限配置无关先把连通性解决。报错四reading choices相关错误这个一般出现在响应解析阶段可能是模型返回格式和 CLI 预期不一致。检查--model指定的模型 ID 是否正确是否在平台支持的列表里。模型 ID 写错有时不会立刻报错而是在解析响应时才暴露。报错五OAuth 相关提示如果你之前用官方账号登录过CLI 可能缓存了 OAuth 凭证和 API Key 模式冲突。清理一下配置目录里的凭证缓存或者显式用 API Key 模式启动。确认环境变量优先级高于缓存的登录态。报错六配置改了但不生效九成是字段名或文件位置的问题。config.toml用下划线approval_modesettings.json用驼峰approvalMode。项目级配置和用户级配置的优先级也要确认项目级通常覆盖用户级。改完重启进程。排查通用思路先加--debug看完整事件流定位是接入失败、权限拦截还是执行出错。接入问题看 401/连接类报错权限问题看requires user confirmation执行问题看工具本身的 stderr。分清楚这三层排查就快了。6. 把统一 Key 接入你的自动化链路权限配好、验证跑通之后剩下的就是把它固化到你的工作流里。这里给几个实操建议。CI 里建议用default模式加白名单别用yolo。白名单按任务最小化配置只读任务就只放read_file、search_files、run_shell_command(git)需要写文件的任务再加write_to_file并限制路径。每个 job 的权限需求不一样别图省事全放开。Key 管理上TaoToken 的统一 Key 让你在多个 CLI 工具间共用一套凭证减少维护成本。团队里把 Key 放进 CI 的 secrets本地开发用环境变量别提交到仓库。需要长期跑编码任务或 Agent 场景的可以看下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan想先手动验证模型行为的用模型对话页面快速试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentchat接入文档和 API Keys 页面在前面已经给过配置过程中对着文档核对字段名能省不少时间。最后说个实际经验非交互模式的工具调用链路调试成本主要在权限判断那一步。把--debug日志留着每次改配置后跑一次最小验证命令确认目标工具能过、危险工具被拦再上 CI。这样出问题时你手里有对照不用从零猜。