拓冰网站定制 
Roo Code 3.15.1 补丁发布解读自动批准重试、终端 stderr 捕获与通知声音策略的修复细节【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-CodeRoo Code 3.15.1 是 2025-04-30 发布的一个补丁版本聚焦于三个 Bug 修复与一项体验改进重试行为对齐全局自动批准开关、历史视图选择模式修复、集成终端对 execa 派生进程 stderr 的捕获以及仅在真正需要用户介入时才播放通知音。本文将逐项解析这些修复的实际意义并结合仓库源码说明其底层实现原理帮助使用者理解该版本的行为变化并据此调整自己的 Roo Code 配置。版本概览3.15.1 属于小步快跑的补丁版本改动克制、目标明确没有引入新功能或破坏性变更而是对既有行为做精细化修正。变更内容集中在以下四个层面变更类别主题影响面Bug 修复重试行为尊重全局自动批准开关自动批准Auto Approve流程Bug 修复历史视图History View选择模式问题任务历史管理界面Bug 修复集成终端捕获 execa 派生进程的 stderr终端输出采集体验改进仅在需要用户操作时播放通知音声音反馈策略该版本的完整变更记录见 v3.15.1.md。下面结合 Roo Code 的源码逐项展开。修复一重试行为尊重全局自动批准开关问题背景Roo Code 支持自动批准Auto Approval机制当用户开启自动批准后读取类、写入类、命令执行、MCP 调用等操作可以跳过人工确认直接执行。但在 3.15.1 之前某些“请求失败后的重试”路径没有纳入自动批准的判定范围——即使全局自动批准被关闭重试也可能绕过确认流程直接发起形成与用户意图不一致的操作。实现原理自动批准判定的核心入口是 checkAutoApproval 函数export async function checkAutoApproval({ state, ask, text, isProtected, }: { state?: PickExtensionState, AutoApprovalState | AutoApprovalStateOptions ask: ClineAsk text?: string isProtected?: boolean }): PromiseCheckAutoApprovalResult { if (isNonBlockingAsk(ask)) { return { decision: approve } } if (!state || !state.autoApprovalEnabled) { return { decision: ask } } // ... }关键逻辑在第二个分支当autoApprovalEnabled即全局自动批准开关为 false 或未定义时判定结果直接落到ask询问用户不会自动放行。3.15.1 的修复就是确保“重试”路径同样走这一判定函数让全局开关对所有请求包括失败后的重试一致生效。同一文件中的AutoApprovalState类型完整列举了可被自动批准的动作类别见 src/core/auto-approval/index.tsexport type AutoApprovalState | alwaysAllowReadOnly | alwaysAllowWrite | alwaysAllowMcp | alwaysAllowModeSwitch | alwaysAllowSubtasks | alwaysAllowExecute | alwaysAllowFollowupQuestions配套的状态选项还包括autoApprovalEnabled、allowedCommands、deniedCommands、followupAutoApproveTimeoutMs等说明全局开关与各类细粒度放行策略是叠加生效的全局开关是总闸各类alwaysAllow*是细分闸门。重试在任务执行链路中的位置在任务执行核心 Task.ts 中重试被设计为一次带计数器的栈重入retryAttempt从 0 开始计数每次失败重试时递增流中断stream failed时会通过backoffAndAnnounce退避后把相同内容重新压栈见 Task.ts首次失败存在“grace retry”静默重试一次机制见 Task.ts上下文窗口溢出类错误有专门的MAX_CONTEXT_WINDOW_RETRIES 3上限见 Task.ts。正因为重试存在多种触发路径流中断、空响应、上下文窗口超限、限流修复必须保证所有路径在发起下一次请求前都重新经过checkAutoApproval而非沿用失败前的旧判定结果。这一点从 3.15.1 的修复描述“Made retries respect the global auto-approve checkbox”可以印证此前的某个重试分支跳过了该检查。对使用者的意义如果你习惯关闭自动批准、人工审核每个操作3.15.1 之后可以放心失败后的自动重试同样需要你的确认不会被“悄悄”放行。如果你依赖自动批准跑无人值守任务此修复不影响正常的自动批准流程重试仍会按你的开关状态继续放行。相关自动批准判定的测试覆盖见 src/core/auto-approval/tests/commands.spec.ts。修复二历史视图选择模式 Bug问题背景历史视图History View用于查看、恢复和继续过往任务会话。3.15.1 之前在该视图中存在一个选择selection相关的交互缺陷——感谢贡献者 jr 的定位与修复。从源码结构看历史视图相关的展示与交互逻辑位于 ClineProvider.ts扩展端状态管理与消息转发以及 webview 端的聊天组件 ChatView.tsx 中。历史任务的加载、恢复、继续会经过taskWithAggregatedCosts等消息通道把历史会话重新注入当前界面见 ChatView.tsx。修复意义该修复属于典型的界面交互层修正确保用户在选择历史任务条目、进入选择态、再切换回正常态时界面高亮与选中状态与底层数据保持一致避免出现“选中的任务与实际恢复的任务不一致”的错位问题。对于频繁在多个历史任务之间切换的用户这一修复直接提升了历史视图的可信度与操作流畅性。修复三集成终端捕获 execa 派生进程的 stderr问题背景Roo Code 的终端抽象层基于两类进程实现一类直接使用 VSCode 终端Terminal/TerminalProcess另一类通过execa派生ExecaTerminal/ExecaTerminalProcess。3.15.1 之前新集成的 execa 终端在采集输出时遗漏了子进程写入stderr的内容导致部分错误信息如编译错误、命令失败原因对 Agent 不可见影响问题诊断。实现原理终端进程的公共基类为 BaseTerminalProcess.ts它定义了run、continue等抽象接口并实现了退出码到信号的解析interpretExitCode见 BaseTerminalProcess.ts退出码大于 128 时会被解释为收到对应信号如SIGINT、SIGTERM并标注该信号是否可能产生 core dump。退出码的准确解析依赖完整的输出采集因此 stderr 缺失会直接影响异常退出的诊断质量。该目录下的测试见 src/integrations/terminal/tests/会针对不同平台win32 的2nul与类 Unix 的2/dev/null做输出对比验证终端进程的 stderr 行为是否符合预期。3.15.1 的修复正是让 execa 派生进程的输出监听同时覆盖 stdout 与 stderr使 Agent 能够看到完整的命令输出与错误信息。对使用者的意义如果你用 Roo Code 执行构建、测试、静态检查等命令修复后错误信息将完整进入 Agent 的上下文Agent 能更准确地基于 stderr 定位并修复问题。该修复只影响新的集成终端execa 派生路径原有基于 VSCode 终端的执行路径不受影响。体验改进仅在需要用户操作时播放通知音问题背景此前只要声音开关开启Roo Code 会在多种事件发生时播放通知音notification.wav包括一些并不需要用户介入的静默推进事件容易造成频繁打扰。感谢贡献者 olearycrew 的改进3.15.1 起通知音只在“需要用户采取行动”时播放。实现原理声音播放由 webview 端统一管理实现在 ChatView.tsxconst volume typeof soundVolume number ? soundVolume : 0.5 const [playNotification] useSound(${audioBaseUri}/notification.wav, { volume, soundEnabled, interrupt: true }) const [playCelebration] useSound(${audioBaseUri}/celebration.wav, { volume, soundEnabled, interrupt: true }) const [playProgressLoop] useSound(${audioBaseUri}/progress_loop.wav, { volume, soundEnabled, interrupt: true }) const playSound useCallback( (audioType: AudioType) { if (!soundEnabled) { return } const now Date.now() const lastPlayed lastPlayedRef.current[audioType] ?? 0 if (now - lastPlayed 100) { return } // debounce: skip if played within 100ms lastPlayedRef.current[audioType] now // ... }, [soundEnabled, playNotification, playCelebration, playProgressLoop], )实现要点总开关soundEnabled为 false 时直接返回不播放任何声音该开关由扩展端全局状态管理读写逻辑见 ClineProvider.ts。音量默认volume 0.5可配置。防抖同一音频类型 100ms 内的重复播放会被跳过避免通知风暴。三类音频notification.wav需要用户介入时、celebration.wav任务完成庆祝、progress_loop.wav请求失败/等待循环提示音频资源位于 webview-ui/audio/。3.15.1 的核心改动体现在触发点的收紧通知音notification目前主要在interactionRequired消息到达时触发见 ChatView.tsxcase interactionRequired: playSound(notification) break即“需要用户操作”这一消息类型成为播放通知音的判据而任务正常推进等无需用户介入的事件不再发声。对应的行为回归测试见 ChatView.notification-sound.spec.tsx。对使用者的意义开启通知音的用户将获得更克制的听觉反馈只有当你需要回应 Roo Code如批准操作、回答追问、处理失败请求时才会听到提示长时间无人值守运行时的噪音明显减少。声音配置入口不变在 Roo Code 设置中切换“启用通知声音”与音量即可无需任何迁移动作。升级建议3.15.1 为纯补丁版本升级风险极低建议所有用户尽快更新若使用自动批准升级后建议抽查一次失败重试的确认行为确认与你设置的自动批准策略一致若依赖终端错误输出排障升级后可重新执行此前因 stderr 缺失而诊断困难的命令观察错误信息是否完整呈现通知声音策略的变化是行为性的若此前觉得提示音过于频繁升级后的体验会自然改善。总结Roo Code 3.15.1 用一次克制的补丁修复完成了三类关键行为的对齐重试尊重自动批准总闸、历史视图选择状态修正、execxca 终端补齐 stderr 采集同时把通知音收敛到“真正需要用户介入”的场景。对于追求自动化效率与低干扰协作体验的开发者这三个修复点分别对应了正确性、界面一致性与反馈质量三个维度的提升值得关注与验证。【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Roo Code 3.15.1 补丁发布解读：自动批准重试、终端 stderr 捕获与通知声音策略的修复细节
Roo Code 3.15.1 补丁发布解读自动批准重试、终端 stderr 捕获与通知声音策略的修复细节【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-CodeRoo Code 3.15.1 是 2025-04-30 发布的一个补丁版本聚焦于三个 Bug 修复与一项体验改进重试行为对齐全局自动批准开关、历史视图选择模式修复、集成终端对 execa 派生进程 stderr 的捕获以及仅在真正需要用户介入时才播放通知音。本文将逐项解析这些修复的实际意义并结合仓库源码说明其底层实现原理帮助使用者理解该版本的行为变化并据此调整自己的 Roo Code 配置。版本概览3.15.1 属于小步快跑的补丁版本改动克制、目标明确没有引入新功能或破坏性变更而是对既有行为做精细化修正。变更内容集中在以下四个层面变更类别主题影响面Bug 修复重试行为尊重全局自动批准开关自动批准Auto Approve流程Bug 修复历史视图History View选择模式问题任务历史管理界面Bug 修复集成终端捕获 execa 派生进程的 stderr终端输出采集体验改进仅在需要用户操作时播放通知音声音反馈策略该版本的完整变更记录见 v3.15.1.md。下面结合 Roo Code 的源码逐项展开。修复一重试行为尊重全局自动批准开关问题背景Roo Code 支持自动批准Auto Approval机制当用户开启自动批准后读取类、写入类、命令执行、MCP 调用等操作可以跳过人工确认直接执行。但在 3.15.1 之前某些“请求失败后的重试”路径没有纳入自动批准的判定范围——即使全局自动批准被关闭重试也可能绕过确认流程直接发起形成与用户意图不一致的操作。实现原理自动批准判定的核心入口是 checkAutoApproval 函数export async function checkAutoApproval({ state, ask, text, isProtected, }: { state?: PickExtensionState, AutoApprovalState | AutoApprovalStateOptions ask: ClineAsk text?: string isProtected?: boolean }): PromiseCheckAutoApprovalResult { if (isNonBlockingAsk(ask)) { return { decision: approve } } if (!state || !state.autoApprovalEnabled) { return { decision: ask } } // ... }关键逻辑在第二个分支当autoApprovalEnabled即全局自动批准开关为 false 或未定义时判定结果直接落到ask询问用户不会自动放行。3.15.1 的修复就是确保“重试”路径同样走这一判定函数让全局开关对所有请求包括失败后的重试一致生效。同一文件中的AutoApprovalState类型完整列举了可被自动批准的动作类别见 src/core/auto-approval/index.tsexport type AutoApprovalState | alwaysAllowReadOnly | alwaysAllowWrite | alwaysAllowMcp | alwaysAllowModeSwitch | alwaysAllowSubtasks | alwaysAllowExecute | alwaysAllowFollowupQuestions配套的状态选项还包括autoApprovalEnabled、allowedCommands、deniedCommands、followupAutoApproveTimeoutMs等说明全局开关与各类细粒度放行策略是叠加生效的全局开关是总闸各类alwaysAllow*是细分闸门。重试在任务执行链路中的位置在任务执行核心 Task.ts 中重试被设计为一次带计数器的栈重入retryAttempt从 0 开始计数每次失败重试时递增流中断stream failed时会通过backoffAndAnnounce退避后把相同内容重新压栈见 Task.ts首次失败存在“grace retry”静默重试一次机制见 Task.ts上下文窗口溢出类错误有专门的MAX_CONTEXT_WINDOW_RETRIES 3上限见 Task.ts。正因为重试存在多种触发路径流中断、空响应、上下文窗口超限、限流修复必须保证所有路径在发起下一次请求前都重新经过checkAutoApproval而非沿用失败前的旧判定结果。这一点从 3.15.1 的修复描述“Made retries respect the global auto-approve checkbox”可以印证此前的某个重试分支跳过了该检查。对使用者的意义如果你习惯关闭自动批准、人工审核每个操作3.15.1 之后可以放心失败后的自动重试同样需要你的确认不会被“悄悄”放行。如果你依赖自动批准跑无人值守任务此修复不影响正常的自动批准流程重试仍会按你的开关状态继续放行。相关自动批准判定的测试覆盖见 src/core/auto-approval/tests/commands.spec.ts。修复二历史视图选择模式 Bug问题背景历史视图History View用于查看、恢复和继续过往任务会话。3.15.1 之前在该视图中存在一个选择selection相关的交互缺陷——感谢贡献者 jr 的定位与修复。从源码结构看历史视图相关的展示与交互逻辑位于 ClineProvider.ts扩展端状态管理与消息转发以及 webview 端的聊天组件 ChatView.tsx 中。历史任务的加载、恢复、继续会经过taskWithAggregatedCosts等消息通道把历史会话重新注入当前界面见 ChatView.tsx。修复意义该修复属于典型的界面交互层修正确保用户在选择历史任务条目、进入选择态、再切换回正常态时界面高亮与选中状态与底层数据保持一致避免出现“选中的任务与实际恢复的任务不一致”的错位问题。对于频繁在多个历史任务之间切换的用户这一修复直接提升了历史视图的可信度与操作流畅性。修复三集成终端捕获 execa 派生进程的 stderr问题背景Roo Code 的终端抽象层基于两类进程实现一类直接使用 VSCode 终端Terminal/TerminalProcess另一类通过execa派生ExecaTerminal/ExecaTerminalProcess。3.15.1 之前新集成的 execa 终端在采集输出时遗漏了子进程写入stderr的内容导致部分错误信息如编译错误、命令失败原因对 Agent 不可见影响问题诊断。实现原理终端进程的公共基类为 BaseTerminalProcess.ts它定义了run、continue等抽象接口并实现了退出码到信号的解析interpretExitCode见 BaseTerminalProcess.ts退出码大于 128 时会被解释为收到对应信号如SIGINT、SIGTERM并标注该信号是否可能产生 core dump。退出码的准确解析依赖完整的输出采集因此 stderr 缺失会直接影响异常退出的诊断质量。该目录下的测试见 src/integrations/terminal/tests/会针对不同平台win32 的2nul与类 Unix 的2/dev/null做输出对比验证终端进程的 stderr 行为是否符合预期。3.15.1 的修复正是让 execa 派生进程的输出监听同时覆盖 stdout 与 stderr使 Agent 能够看到完整的命令输出与错误信息。对使用者的意义如果你用 Roo Code 执行构建、测试、静态检查等命令修复后错误信息将完整进入 Agent 的上下文Agent 能更准确地基于 stderr 定位并修复问题。该修复只影响新的集成终端execa 派生路径原有基于 VSCode 终端的执行路径不受影响。体验改进仅在需要用户操作时播放通知音问题背景此前只要声音开关开启Roo Code 会在多种事件发生时播放通知音notification.wav包括一些并不需要用户介入的静默推进事件容易造成频繁打扰。感谢贡献者 olearycrew 的改进3.15.1 起通知音只在“需要用户采取行动”时播放。实现原理声音播放由 webview 端统一管理实现在 ChatView.tsxconst volume typeof soundVolume number ? soundVolume : 0.5 const [playNotification] useSound(${audioBaseUri}/notification.wav, { volume, soundEnabled, interrupt: true }) const [playCelebration] useSound(${audioBaseUri}/celebration.wav, { volume, soundEnabled, interrupt: true }) const [playProgressLoop] useSound(${audioBaseUri}/progress_loop.wav, { volume, soundEnabled, interrupt: true }) const playSound useCallback( (audioType: AudioType) { if (!soundEnabled) { return } const now Date.now() const lastPlayed lastPlayedRef.current[audioType] ?? 0 if (now - lastPlayed 100) { return } // debounce: skip if played within 100ms lastPlayedRef.current[audioType] now // ... }, [soundEnabled, playNotification, playCelebration, playProgressLoop], )实现要点总开关soundEnabled为 false 时直接返回不播放任何声音该开关由扩展端全局状态管理读写逻辑见 ClineProvider.ts。音量默认volume 0.5可配置。防抖同一音频类型 100ms 内的重复播放会被跳过避免通知风暴。三类音频notification.wav需要用户介入时、celebration.wav任务完成庆祝、progress_loop.wav请求失败/等待循环提示音频资源位于 webview-ui/audio/。3.15.1 的核心改动体现在触发点的收紧通知音notification目前主要在interactionRequired消息到达时触发见 ChatView.tsxcase interactionRequired: playSound(notification) break即“需要用户操作”这一消息类型成为播放通知音的判据而任务正常推进等无需用户介入的事件不再发声。对应的行为回归测试见 ChatView.notification-sound.spec.tsx。对使用者的意义开启通知音的用户将获得更克制的听觉反馈只有当你需要回应 Roo Code如批准操作、回答追问、处理失败请求时才会听到提示长时间无人值守运行时的噪音明显减少。声音配置入口不变在 Roo Code 设置中切换“启用通知声音”与音量即可无需任何迁移动作。升级建议3.15.1 为纯补丁版本升级风险极低建议所有用户尽快更新若使用自动批准升级后建议抽查一次失败重试的确认行为确认与你设置的自动批准策略一致若依赖终端错误输出排障升级后可重新执行此前因 stderr 缺失而诊断困难的命令观察错误信息是否完整呈现通知声音策略的变化是行为性的若此前觉得提示音过于频繁升级后的体验会自然改善。总结Roo Code 3.15.1 用一次克制的补丁修复完成了三类关键行为的对齐重试尊重自动批准总闸、历史视图选择状态修正、execxca 终端补齐 stderr 采集同时把通知音收敛到“真正需要用户介入”的场景。对于追求自动化效率与低干扰协作体验的开发者这三个修复点分别对应了正确性、界面一致性与反馈质量三个维度的提升值得关注与验证。【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考