Continue CLI 权限系统详解从三种权限类型到 headless 模式的完整安全实践【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue本篇技术指南聚焦 Continue 开源编程代理open-source coding agent中Continue CLIcn命令的权限系统设计。权限系统用于让用户全程掌控 LLM 对工具工具即能力如读写文件、执行终端命令的调用行为是该 CLI 在自动化执行与用户可控之间取得平衡的核心机制。读完本文你将掌握allow/ask/exclude三种权限语义、五层规则优先级、normal/plan/auto三种运行模式、工具匹配模式含Read(**/*.ts)这类参数级 glob以及命令行标志与~/.continue/permissions.yaml的完整配置方法并能安全地在 headless-p/--print场景下使用工具。为什么需要权限系统让用户掌控 LLM 的每一次动作在 agent 式编程工具中LLM 会自动发起工具调用——读取文件、搜索代码、执行命令、写入改动。如果这些动作不可见、不可控用户将面临两个风险一是模型误操作导致文件被意外改写二是终端命令可能带来破坏性副作用。为此Continue CLI 实现了一套分层权限系统核心目标写在规范文档 extensions/cli/spec/permissions.md 中让用户可以监督overseeLLM 的每一个动作。从架构上看权限判定发生在工具调用执行之前由 extensions/cli/src/permissions/permissionChecker.ts 中的checkToolPermission统一完成先按策略列表静态匹配出基础权限再允许工具自身通过evaluateToolCallPolicy做动态策略评估若动态评估结果为disabled则始终以exclude为准否则以用户配置的基础权限为准。这一设计保证了用户偏好优先、工具自保兜底。三种权限类型allow / ask / exclude每个工具都会被赋予以下三种权限之一定义于 extensions/cli/src/permissions/types.ts 中的PermissionPolicy类型权限语义模型视角allow工具被自动调用无需询问用户模型可见、可直接使用ask调用前向用户请求确认用户可选择接受或拒绝模型可见、但需人工放行exclude工具被完全排除模型甚至不知道它存在模型完全不可见exclude的实现要点是工具过滤被排除的工具在发送给模型之前就被过滤掉而不是调用了再拒绝。这一点在 extensions/cli/src/permissions/README.md 的 Tool Filtering (Exclude Policy) 一节有明确说明——The AI wont even know these tools exist从根上杜绝了模型尝试调用被禁工具的可能。与之配套的数据结构是ToolPermissionPolicyexport interface ToolPermissionPolicy { /** 要匹配的工具名 */ tool: string; /** 应用的权限 */ permission: PermissionPolicy; /** 可选的参数匹配模式不指定则匹配该工具的所有调用 */ argumentMatches?: Recordstring, any; }argumentMatches正是支撑Read(**/*.ts)只匹配读取 TS 文件这类参数级策略的字段。规则优先级五层策略如何叠加不同来源的权限策略可能互相冲突因此规范定义了严格的优先级顺序前者优先模式策略最高优先级见 extensions/cli/spec/modes.md命令行标志--allow、--ask、--excludeconfig.yaml/ 配置中的permissions段~/.continue/permissions.yaml默认策略default policies需要注意的是先匹配先生效是在逐工具per-tool层面发生的也就是说高优先级来源会完全覆盖低优先级来源对同一工具的设置。这一逻辑在 extensions/cli/src/permissions/precedenceResolver.ts 的resolvePermissionPrecedence中有完整实现它依次追加命令行标志策略 → 个人设置~/.continue/permissions.yaml策略 → 默认策略靠数组顺序靠前者先被匹配来实现优先级。默认策略读放行、写询问内置工具的默认权限集定义在 extensions/cli/src/permissions/defaultPolicies.ts 的getDefaultToolPolicies(isHeadless)中其核心原则是写类工具需要确认Edit、MultiEdit、Write均为ask读类工具直接放行Read、List、Search、Status、Diff等均为allow执行类需要确认TUI 模式下Bash为ask兜底通配符TUI 模式下*为ask任何未显式配置的工具默认询问。内置的 15 个工具如Fetch、AskQuestion、Checklist、Exit、UploadArtifact、ReportFailure、Skills、CheckBackgroundJob默认均为allow只有写类与 Bash 默认需要确认。这些行为有集成测试覆盖例如 extensions/cli/src/permissions/headlessPermissions.integration.test.ts 断言了Read/List/Search返回allow、Write返回ask的默认规则。三种模式normal / plan / auto模式是对权限体系的最高层干预。规范原文强调在 plan 和 auto 模式下模式策略完全覆盖completely override所有其他权限设置忽略用户配置。三种模式的定位如下模式行为说明normal无模式策略使用既有配置permissions.yaml 命令行覆盖 默认策略plan绝对覆盖——排除所有写工具、只允许读工具忽略用户配置只读分析场景auto绝对覆盖——所有工具免询问放行忽略用户配置最大化自动化plan 模式对应旧版--readonly标志向后兼容UI 以蓝色[plan]标识实现上对应defaultPolicies.ts中的PLAN_MODE_POLICIESL43-L66将Edit/MultiEdit/Write设为exclude同时允许Bash、Read、Search等分析所需工具以及全部 MCP 工具。auto 模式对应--auto标志UI 以绿色[auto]标识实现上对应AUTO_MODE_POLICIESL69-L71仅一条*: allow通配策略。动态切换在对话会话中可通过ShiftTab在 normal → plan → auto 之间循环切换。切换逻辑实现在 extensions/cli/src/services/ToolPermissionService.ts 的switchMode中离开 normal 模式时深拷贝保存原始策略切回 normal 时恢复保证用户配置不丢失。从源码看模式判定与策略组装由ToolPermissionService的generateModePolicies与initializeSync完成plan/auto 模式只使用模式策略绝对覆盖normal 模式才走resolvePermissionPrecedence合并用户配置与默认策略。工具匹配模式从全量匹配到参数级 glob要让一条策略精确作用于某个工具规范定义了工具匹配模式tool matching pattern格式如下Read匹配任意对Read工具的调用Read(*)同样匹配任意对Read工具的调用括号内为通配Read(**/*.ts)只匹配Read工具中主参数对Read而言是file_path符合 glob 模式**/*.ts的调用。此外Bash 工具支持命令级匹配例如Bash(ls*)只匹配以ls开头的终端命令。这个特殊分支在 extensions/cli/src/permissions/permissionChecker.ts 的matchesToolPatternL17-L61中有专门实现它将*/?转换为等价正则并对command参数做全匹配无通配符时则做精确命令匹配。参数级匹配的底层映射关系工具 → 主参数键定义在 extensions/cli/src/permissions/permissionsYamlLoader.ts 的parseToolPatternL77-L117中工具主参数键Write/Edit/Read/Difffile_pathListpathSearchqueryBashcommandFetchurl其他工具默认patternmatchesArgumentsL67-L104负责将这些 glob 模式逐个与调用参数比对。规范同时提醒对exclude策略而言参数匹配没有意义——既然要完全屏蔽某个工具就不需要再关心它被调用时的参数。命令行标志--allow / --ask / --exclude--allow、--ask、--exclude三个标志分别允许你为工具设置对应权限其参数必须是上述工具匹配模式。每个标志的取值会按顺序追加到策略列表中在 extensions/cli/src/permissions/runtimeOverrides.ts 与precedenceResolver.ts中顺序固定为 exclude → ask → allow。规范给出的实操示例# 允许 Read、询问 Write、排除 Bash cn --allow Read --ask Write --exclude Bash # 以 plan 模式启动只读工具 命令执行 cn --readonly Help me understand this codebase # 在对话中使用模式切换 cn Let me work on this feature # 默认 normal 模式启动 # 之后按 ShiftTab 循环切换模式命令行标志属于优先级第 2 层仅低于模式策略也就是说在 plan/auto 模式下你传入的--allow写工具标志会被模式策略覆盖见 extensions/cli/spec/modes.md 中 User config ignored 的说明。config.yaml 中的 permissions 配置规范在 extensions/cli/spec/permissions.md 的 config.yaml / Configuration 一节说明用户可把权限写进自定义 assistant 的config.yaml的permissions段结构如下permissions: allow: - Read(*) ask: - Write(**/*.py) exclude: - Write需要注意规范文档在该节明确标注了 This should not be implemented yet.此功能尚未实现 的提示属于规划中的能力。因此在实际使用中这一配置段目前应由命令行标志与个人设置文件承担见下一节。~/.continue/permissions.yaml个人设置与持久化如果每个 assistant 都要重复配置权限体验会非常繁琐。因此 CLI 提供了个人设置文件~/.continue/permissions.yaml其结构与config.yaml的permissions段基本等价allow: - Read(*) ask: - Write(**/*.py) exclude: - Write但有一个关键区别值得强调规范原文措辞这个文件并非设计给用户手动编辑的。它只用于持久化persistence用户应该通过 TUI 界面来交互式地调整权限文件本身由 CLI 在首次启动时自动创建。源码印证了这一点文件路径由PERMISSIONS_YAML_PATH~/.continue/permissions.yaml定义于 extensions/cli/src/permissions/permissionsYamlLoader.tsensurePermissionsYamlExistsL152-L179会在目录不存在时递归创建、文件不存在时写入带注释的默认空配置allow: []/ask: []/exclude: []并由ToolPermissionService.doInitialize在 CLI 首次启动时触发。加载器还会校验文件结构只允许allow/ask/exclude三个键且值为数组结构非法时安全降级为null并记录告警。yamlConfigToPolicies将 YAML 内容转换为策略时同样遵循更严格的策略在前的顺序先exclude再ask最后allow确保同一工具的多个来源中限制性最强的规则先被匹配。Headless 模式权限安全默认 显式放行使用-p/--print标志运行 headless 模式一次性、非交互地让 CLI 完成任务并打印结果时权限行为需要特别设计——因为没有交互界面可以弹出确认框。规范给出的行为是Normal 模式写操作与终端命令需要确认ask用户会被提示Headless 模式使用相同的默认策略但需要确认ask的工具将导致进程以错误信息退出而不是等待用户输入。这就意味着在 headless 场景下使用默认需要确认的工具你必须显式放行它们。规范示例# headless 模式 显式允许写文件工具 cn -p --allow write_file Write a hello world script # headless 模式 通配符权限允许所有工具 cn -p --allow * Write and run a script # headless 模式 特定限制 cn -p --exclude run_terminal_command Clean up the codebase这样既保证了 headless 模式默认安全secure by default又给出了清晰的放行路径。从实现细节看headless 标记会传入getDefaultToolPolicies(isHeadless)当isHeadless为true时Bash与兜底通配符*的默认权限被设为allow见 extensions/cli/src/permissions/defaultPolicies.ts配合precedenceResolver的isHeadless选项ToolPermissionService会在初始化时将其纳入策略组装同时 extensions/cli/spec/tty-less-support.md 也提到 headless 模式下会阻止 TUI 启动二者共同保证非交互运行不会卡在等待用户确认上。权限系统架构小结综合规范与源码Continue CLI 的权限系统由以下模块协同工作策略定义extensions/cli/src/permissions/types.ts ——PermissionPolicy、ToolPermissionPolicy、ToolCallRequest等核心类型默认策略extensions/cli/src/permissions/defaultPolicies.ts —— 内置工具默认权限 plan/auto 模式策略匹配与判定extensions/cli/src/permissions/permissionChecker.ts ——matchesToolPattern/matchesArguments/checkToolPermission含 Bash 命令级匹配与工具动态策略评估优先级合并extensions/cli/src/permissions/precedenceResolver.ts —— 命令行标志 → 个人设置 → 默认策略的逐层追加个人设置加载extensions/cli/src/permissions/permissionsYamlLoader.ts —— YAML 解析、模式解析与首启自动创建运行时服务extensions/cli/src/services/ToolPermissionService.ts —— 模式切换、headless 状态、权限重载并通过 ServiceContainer 驱动响应式 UI测试覆盖extensions/cli/src/permissions/defaultPolicies.test.ts、permissionChecker.test.ts、precedenceResolver.test.ts、permissionsYamlLoader.test.ts、headlessPermissions.integration.test.ts 等。整体数据流为工具加载阶段过滤掉exclude的工具 → 每次工具调用前进行权限检查 →ask工具在 TUI 中弹出确认y/n→ 按结果执行或拒绝。这套设计把用户监督落在每一次工具调用上同时通过模式与命令行标志提供了从全自动到全手动的灵活度调节空间是安全使用 agent 类 CLI 的关键基础设施。【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考