From 873601fde62b467a13e4645538de978b0bc9e612 Mon Sep 17 00:00:00 2001 From: Leeeon233 Date: Wed, 9 Sep 2026 09:24:28 +0800 Subject: [PATCH 1/3] fix: integrate Grok YOLO permission fallback Model: gpt-6 --- ...6-09-08-grok-acp-permission-fallback.zh.md | 49 +++++ ...k-always-approve-permission-analysis.zh.md | 192 ++++++++++++++++++ apps/cli/src/agent/AGENTS.md | 4 +- apps/cli/src/agent/README.md | 22 +- packages/acp-extension-grok | 2 +- packages/shared/src/ai.ts | 5 - packages/shared/tests/ai-grok.test.ts | 1 - specs/grok-permission-fallback.zh.md | 47 +++++ 8 files changed, 304 insertions(+), 18 deletions(-) create mode 100644 .agents/notes/implemented/bug-fix/2026-09-08-grok-acp-permission-fallback.zh.md create mode 100644 .agents/notes/proposed/bug-fix/2026-09-08-grok-always-approve-permission-analysis.zh.md create mode 100644 specs/grok-permission-fallback.zh.md diff --git a/.agents/notes/implemented/bug-fix/2026-09-08-grok-acp-permission-fallback.zh.md b/.agents/notes/implemented/bug-fix/2026-09-08-grok-acp-permission-fallback.zh.md new file mode 100644 index 000000000..be09bc2b0 --- /dev/null +++ b/.agents/notes/implemented/bug-fix/2026-09-08-grok-acp-permission-fallback.zh.md @@ -0,0 +1,49 @@ +# Grok ACP 移除 Auto 并在 YOLO 下直接回应允许选项 + +Status: implemented +Translation: pending + +## 摘要 + +官方 Grok 在 YOLO 下仍可能发送工具权限请求，客户端处理时可能先暴露待批准状态。 +本次在 Grok ACP 扩展内直接回应这类请求，优先单次允许，没有单次允许时选择持续允许， +并从扩展和静态能力中移除 Auto。没有允许选项和用户问题仍保持交互，旧 Auto 启动配置 +按 Ask 恢复。代价是扩展直接处理的请求不进入 Lody 权限历史，持续允许选项也可能在 +官方运行时保存授权；普通工具更新仍转发。 + +## 决定与已有分析的关系 + +这是[先前分析](../../proposed/bug-fix/2026-09-08-grok-always-approve-permission-analysis.zh.md) +之后采用的扩展层兜底方案。它替代该分析建议的“在 Lody 历史中原子发布自动批准”作为 +新 Grok 扩展请求的处理方式，没有实现输入框实时权限切换，也没有改写先前分析中的 +历史证据。产品语义记录为 [Spec 草案](../../../../specs/grok-permission-fallback.zh.md)。 + +## 实现 + +- `proxy.js` 去除 Auto 选项和启用 Auto 的通知路径，启动时旧值归一为 Ask，显式发送 + `autoMode=false`；live Auto 请求返回错误，不改变已接受配置。 +- `handleRuntimeMethod` 对已知 YOLO 会话的新权限请求，依据标准 kind 先找 + `allow_once` 再找 `allow_always`，直接向 runtime 返回原请求 id 的 selected outcome。 + 不向客户端转发已回答的请求，不用文字匹配推测允许。 +- 用户问题元数据、标准 elicitation、模式切换审批、未知会话和没有可用允许选项的请求继续透传。 +- 保持反向请求与客户端请求 id 空间独立，Ask 模式及其他客户端所属会话不受影响。 +- Lody 静态 Grok 能力同步移除 Auto，避免打开选择器时仍提供已移除选项。 +- Lody 原有客户端 `allow_once` 路径保留，处理旧扩展和此前已经转发的请求；说明和 + scoped AGENTS 明确这两层的不同责任。 + +## 验证与限制 + +扩展测试在临时副本中使用当前 Core 编译产物执行，57/57 通过，覆盖启动及恢复、 +模式切换、Plan 审批保持交互、AllowAlways 兜底、客户端隔离、透传边界和双向 id 冲突。 +从实际源码提取静态能力常量的探针确认其权限选项与扩展返回列表一致。 +扩展 build（JavaScript 语法检查）、修改代码的 Prettier 检查、文档检查及父仓库和 +子模块的 `git diff --check` 均通过。文档检查保留 18 条原有 AGENTS 大小警告。 +2026-09-09 创建 PR 前，扩展已适配到其 main `f3f59e1`，主仓库集成以 +[独立 Plan PR #503](https://github.com/LodyAI/Lody/pull/503) 为基线，使用 Core 0.1.1。 +扩展版本升至 0.1.3，使能力缓存识别新的权限选项；依赖解析未改变，无需锁文件变更。 +尝试 `pnpm check` 与 `pnpm format`，当前工作树缺少 node_modules，分别在 +`tsgo`、`prettier` 缺失处停止。定向检查通过；没有完整应用或真实模型回合验证。 + +本次修改分为 [Grok 扩展 PR #15](https://github.com/LodyAI/acp-extension-grok/pull/15) +和依赖 #503 的 Lody 集成 PR。 +英文翻译待补。 diff --git a/.agents/notes/proposed/bug-fix/2026-09-08-grok-always-approve-permission-analysis.zh.md b/.agents/notes/proposed/bug-fix/2026-09-08-grok-always-approve-permission-analysis.zh.md new file mode 100644 index 000000000..faaa5f977 --- /dev/null +++ b/.agents/notes/proposed/bug-fix/2026-09-08-grok-always-approve-permission-analysis.zh.md @@ -0,0 +1,192 @@ +# Grok Always Approve 仍显示权限请求的源码分析 + +Status: proposed +Translation: pending + +## 摘要 + +当前 Lody 已实现 Grok 启动时的 YOLO 元数据转换，以及官方客户端对残留权限请求的 +单次自动批准；不能再把弹窗笼统归因于缺少这两项实现。源码中仍存在两条可解释现象的 +路径：聊天选择器只修改未发送配置，当前回合不会立即切换权限；自动批准流程分两次 +写历史，使前端能够观察到尚未批准的中间状态。建议分别明确并实现活动会话的权限切换 +语义，以及让自动批准请求和结果原子发布。本文是分析与修复提案，没有修改运行时代码， +也尚未用报告问题的具体会话确认是哪一条路径触发。 + +## 范围与版本 + +- Lody：`21bd38123f7938e600b2fe135af09917061ea2df`。 +- 固定的 Grok 扩展：`77a994f4e0a5acec8c52020c0a8e01b0e90aaef9`， + [runtime-manifest.json](../../../../packages/acp-extension-grok/runtime-manifest.json) + 指定官方运行时 `1.0.13`。 +- Core：`7bc6332d3f007876895b4a3a827be0060f4d5318`。 +- 2026-09-08 拉取的公开 + [grok-build](https://github.com/xai-org/grok-build/tree/72a61251fcffb464bcc687aeb5a998e5a98ec0c9) + HEAD 为 `72a61251fcffb464bcc687aeb5a998e5a98ec0c9`，提交日期 2026-09-01； + `SOURCE_REV` 为 `a549186d9d39311f2d3ee4208db62af8c65aa476`。 + +公开仓库是官方内部仓库的定期同步，不能据此宣称它和发行二进制 `1.0.13` 完全相同。 +此次没有发起真实模型回合，没有读取或保存用户会话记录，也没有修改 Grok 配置。 + +## 已有实现与官方语义 + +### 会话建立和运行中切换是不同入口 + +[AgentClient](../../../../apps/cli/src/agent/agent-client.ts) 的 +`getSessionStartMeta` 把该回合的 `configOptionValues` 放入 +`_meta.lody.sessionConfig`，builtin Grok 另带 `clientIdentifier=lody:`。 +初始化和 new/load/resume/fork/replacement 路径传递相应元数据。 + +[proxy.js](../../../../packages/acp-extension-grok/src/proxy.js) 的 +`translateSessionStart` 在转发建会话请求之前，把 `permission_mode=always-approve` +转换为 `_meta.yoloMode=true`。官方 +[session_setup.rs](https://github.com/xai-org/grok-build/blob/72a61251fcffb464bcc687aeb5a998e5a98ec0c9/crates/codegen/xai-grok-shell/src/agent/mvp_agent/session_setup.rs#L324) +确实读取这个字段，不能把 camelCase 的启动字段与 snake_case 的通知字段混为一谈。 + +运行中的 `session/set_config_option` 则转换为 `_x.ai/yolo_mode_changed`： + +```json +{ + "clientIdentifier": "lody:synthetic-session", + "permission_mode": "always-approve", + "yolo_mode": true, + "auto_mode": false +} +``` + +官方 +[acp_agent.rs](https://github.com/xai-org/grok-build/blob/72a61251fcffb464bcc687aeb5a998e5a98ec0c9/crates/codegen/xai-grok-shell/src/agent/mvp_agent/acp_agent.rs#L2662) +按 `origin_client.product/clientIdentifier` 找到驻留会话，发送 `SetYoloMode`； +[run_loop.rs](https://github.com/xai-org/grok-build/blob/72a61251fcffb464bcc687aeb5a998e5a98ec0c9/crates/codegen/xai-grok-shell/src/session/acp_session_impl/run_loop.rs#L1146) +再更新权限管理器。通知不是有确认响应的请求，不能为尚不存在的会话建立启动默认值。 + +扩展的 setter 会立即更新自己的 `permissionModes` 并返回 configOptions；因此该响应 +证明扩展接受了选择，不能证明官方运行时已执行或接受它。其 configOptions 中的权限 +值来自扩展自己的 Map，不是读取官方权限管理器的结果。 + +### YOLO 仍可能产生 ACP 权限请求 + +官方 +[权限管理器](https://github.com/xai-org/grok-build/blob/72a61251fcffb464bcc687aeb5a998e5a98ec0c9/crates/codegen/xai-grok-workspace/src/permission/manager/mod.rs#L1721) +的快速批准条件是 `yolo_mode && !shell_forced_prompt && !hook_forced_prompt`。 +shell/file 检查和 Hook 强制询问可以让请求进入交互路径；明确的策略 deny 在 YOLO +之前就拒绝，不会靠客户端批准恢复。受管理策略还可以禁止启用 YOLO。 + +官方 TUI 在 +[permissions.rs](https://github.com/xai-org/grok-build/blob/72a61251fcffb464bcc687aeb5a998e5a98ec0c9/crates/codegen/xai-grok-pager/src/app/acp_handler/permissions.rs#L25) +另做一层处理：所属会话是 YOLO 且提供 `AllowOnce` 时立即返回该选项，不入交互队列。 +启用 YOLO 时， +[modes.rs](https://github.com/xai-org/grok-build/blob/72a61251fcffb464bcc687aeb5a998e5a98ec0c9/crates/codegen/xai-grok-pager/src/app/dispatch/modes.rs#L282) +也会清空已有队列，有 AllowOnce 则单次批准，没有则取消，绝不自动创建永久授权。 + +Lody 的 `827cf22e`（[PR #148](https://github.com/LodyAI/Lody/pull/148)）已加入对应 +客户端行为，当前工作树包含它。规则在 +[lody-acp-extension.ts](../../../../apps/cli/src/agent/lody-acp-extension.ts)， +历史持久化与等待请求收尾由 +[MessageHandler](../../../../apps/cli/src/lib/message-handler.ts) 负责；扩展本身原样转发 +`session/request_permission`。这与 +[现有说明](../../../../apps/cli/src/agent/README.md#grok-permission-handling) +一致。残留 ACP 请求本身不能证明 YOLO 没生效，也不能证明 #148 不存在。 + +## 发现一：输入框的选择不是活动会话的权限切换 + +[session-chat-interface.tsx](../../../../packages/components/src/components/sessions/session-chat-interface.tsx) +直接把 `useAcpSessionConfigSelectionState().selectConfigOption` 作为权限选择回调。 +[该 hook](../../../../packages/components/src/hooks/use-acp-session-config-selection.ts) +只调用 React `setFence`，更新 `edits.configOptions`，没有向 Machine 发出实时配置请求。 + +[配置推导](../../../../packages/components/src/lib/acp-session-config-selection.ts) 又让未发送 +编辑优先于 runtimePreferences。因此以下状态是当前代码允许的： + +```text +当前回合：Ask → 正等待权限 +用户在输入框选择：Always Approve +输入框显示：Always Approve（未发送编辑） +AgentClient 已接受配置：仍是 Ask +自动批准判断：不命中，原请求继续等待 +``` + +选择会随 `buildSessionTurnInputConfig` 进入下一次提交或队列； +[session-execution-service.ts](../../../../apps/cli/src/session/session-execution-service.ts) +在执行回合时调用 `applyAcpModeAndModel`，最后才由 +[配置应用器](../../../../apps/cli/src/session/acp-session-config-applier.ts) +调用 `setSessionConfigOption`。仅排入下一回合也不会解开当前等待请求。 + +这条路径能解释“弹窗后切到 Always Approve，仍一直等批准”；如果在发送当前回合之前 +就已经选择 Always Approve，则需要继续查该回合的实际配置，不能直接归入这个原因。 +客户端的配置订阅和队列清理机制存在，但输入框点击不会触发它。 + +[现有 run-config 说明](../../../docs/sessions-run-config.md) 明确将未发送选择作为私有 +草稿，提交后才进入执行配置。因此这不是已承诺的实时 setter 发生故障，而是当前交互 +语义无法满足“切换后立即放行”的预期；把权限选择改成即时操作属于需要明确的新语义。 + +## 发现二：自动批准前会暴露待批准历史 + +`MessageHandler.handleAgentPermissionRequest` 当前顺序为： + +1. `ensurePermissionRequestOnToolCall` 写入没有 outcome 的 permissionRequest。 +2. 等待 `setLastMessageAt`、`getMetaState`、`getHistory`。 +3. 用 AgentClient 已接受配置计算 automaticOutcome。 +4. 再用 `updatePermissionOutcomeInHistory` 单独写入自动批准结果。 + +[history.ts](../../../../apps/cli/src/lib/acp/history.ts) 的两个操作各自执行一次 +`doc.updateHistory`，中间没有原子发布边界。 +[FloatingPermissionRequest](../../../../packages/components/src/components/sessions/floating-permission-request.tsx) +只要 session 状态是 running 或 requestPermission，并且历史中有尚无 outcome 的请求， +就会显示权限 UI。它不要求后台已经设置 requestPermission 状态。 + +因此，“自动批准分支没有调用 setStatus(requestPermission)”不足以证明前端不会弹窗。 +前端若观察到第一次写入，会显示请求，第二次写入后消失。隔离探针验证了两个历史状态的 +可见性判断；尚未测量真实 Flock 同步是否在某次运行中合并了两次更新，不能宣称每次 +自动批准都必然闪烁。若第二次历史写入失败，后台返回 cancelled，但第一条未解决历史 +可能残留；这是相关错误路径，需要修复时一并验证。 + +## 其余命中条件与定位边界 + +自动批准要求同时满足：builtin Grok、已接受的 `permission_mode` 为精确值 +`always-approve`、普通工具权限请求、包含 `kind=allow_once` 的选项。 + +- custom/registry 启动同一个扩展，不会自动获得 builtin Grok 的客户端规则； + builtin 专用 clientIdentifier 注入也不适用于它们。 +- Auto 和 Always Approve 是不同值；Auto 仍可以询问。 +- 用户问题保持交互，不能为了“全批准”自动选择问题答案。 +- 没有 allow_once 的新请求保持交互，这是当前有意的兼容行为；官方普通权限选项 + 构造通常包含 AllowOnce，尚无证据表明报告问题的请求缺少它。 +- 本文分析的是当前 checkout，不能证明用户实际运行的 daemon/打包扩展已包含 #148。 +- 官方 managed policy 可钳制 YOLO，扩展却可能继续显示乐观值；这是有效状态可观测性 + 的限制，不能直接认定为本次弹窗根因。不要用全局永久授权去消除这种差异。 + +对于“发起回合前已选 Always Approve，普通工具仍永久等待”的复现，下一步应只核对 +客户端/扩展/运行时版本、Provider cliType、该回合请求配置、AgentClient 已接受配置、 +请求是否为问题、选项 kind，以及自动批准结果是否持久化。无需收集 prompt、命令正文、 +凭据或完整用户记录。 + +## 修复提案与取舍 + +1. 若产品要求点击权限模式立即作用于活动会话，需增加明确的运行中配置更新入口， + 在当前执行会话上调用 setter，接受后更新 runtime snapshot 并由已有持久权限流 + 清理队列。明确失败、并发回合、会话归属及运行中切换的语义后再更新 Spec 为 draft； + 不应把所有输入框配置编辑都默认变成实时 RPC。 +2. 如果保持“下一回合配置”的语义，UI 应明确标出未发送选择，避免看起来像当前权限 + 已经改变。这能消除状态误解，但不会提供立即放行能力。 +3. 在持久权限流中预先判断可自动批准的请求，把请求与已选 outcome 放进同一次历史 + 更新，成功持久化后才回复 ACP；保留审计记录、问题交互及显式用户拒绝优先规则。 + 不建议用前端按权限模式隐藏所有弹窗，也不建议在扩展中抢答而绕过 Lody 持久化。 +4. 若未来完善官方有效权限状态同步，应以官方确认/事件为依据；单纯再发一次 YOLO + 通知不能解决输入框未派发或中间历史可见问题。 + +这些是待实现提案；本次没有改变产品意图、Spec 或权限边界。 + +## 验证 + +- 开始时 `pnpm run docs status`：无错误；存在原有翻译债务和 AGENTS 大小警告。 +- 用全局 TypeScript 编译当前 Core 到临时目录；在临时副本中运行扩展的现有测试： + 33/33 通过。测试验证转换、状态和透传，不代表官方二进制端到端批准验证。 +- 从实际源码提取并去除类型后运行确定性探针：验证 builtin allow_once 自动回应、 + 未发送 UI 值覆盖 runtime Ask、两个历史状态分别显示/隐藏权限 UI，以及 custom 和 + 缺少 allow_once 的分支。只使用合成普通权限请求；没有测试问题解析或 React/网络。 +- 当前工作树没有 node_modules，未运行 Lody 完整 Vitest、应用构建或真实模型回合。 + 原有 `message-handler-grok-permissions.test.ts` 主要断言最终结果、状态和订阅， + 没有覆盖上述输入框入口与中间历史在前端的可见性。 +- `pnpm run docs check` 与 `git diff --check` 通过；文档检查保留原有大小警告。 + +没有创建 PR，没有修改运行时代码。英文翻译待补。 diff --git a/apps/cli/src/agent/AGENTS.md b/apps/cli/src/agent/AGENTS.md index 124a9c8e1..2baafd89f 100644 --- a/apps/cli/src/agent/AGENTS.md +++ b/apps/cli/src/agent/AGENTS.md @@ -10,8 +10,8 @@ context/acp-agent-edit-evidence.md; adapter repos: [apps/cli/AGENTS.md](../../AG - Consume Core extensions via `agentCapabilities._meta.lody`, session `_meta.lody`, and `_lody/...`. Provider/pre-Core readers stay in `lody-acp-extension.ts`; consumers stay neutral. -- Grok Always Approve uses `allow_once`, never lasting grants; pending calls drain through - the durable permission flow on accepted config changes. Questions and mode switches remain interactive. +- The client fallback for older Grok adapters uses `allow_once`; pending calls drain through + durable permissions on accepted config changes. Questions and mode switches remain interactive. - Builtin Grok must default `clientCapabilities.terminal` to false. - Send the driving turn's config on every session establishment as `_meta.lody.sessionConfig`; provider-specific startup translation belongs in the ACP adapter. `session/set_config_option` diff --git a/apps/cli/src/agent/README.md b/apps/cli/src/agent/README.md index dcf6fa254..ff86723de 100644 --- a/apps/cli/src/agent/README.md +++ b/apps/cli/src/agent/README.md @@ -42,15 +42,19 @@ context/message-flow.md "Upstream". ### Grok permission handling -Grok's TUI combines the runtime YOLO setting with client-side `AllowOnce` responses. -`lody-acp-extension.ts` owns this compatibility rule for builtin Grok only; -`agent-client.ts` evaluates it against the accepted session config and exposes config -subscriptions. `MessageHandler` persists the selected outcome in the existing permission -history. Enabling Always Approve also drains already waiting requests and clears their UI -state and subscriptions. New requests without `allow_once` stay interactive; the queue -drain cancels such requests, matching the TUI without creating lasting grants. User -questions and other providers do not participate. The Grok adapter passes native requests -through so this durable flow remains their single owner. +Grok's TUI combines the runtime YOLO setting with client-side approval responses. +The current Grok adapter handles incoming Always Approve requests before they +reach Lody: it prefers `allow_once`, then uses `allow_always` if that is the only +allow kind. Auto is removed from both adapter and static capabilities; legacy +startup Auto restores as Ask. Adapter-resolved requests do not create Lody +permission-request history, while ordinary tool updates still pass through. + +`lody-acp-extension.ts` retains the builtin Grok compatibility fallback for older +adapters and requests already forwarded to Lody. It uses only `allow_once`, and +`MessageHandler` persists that outcome through the durable permission flow. +Accepted config changes drain waiting requests and clear UI state/subscriptions; +questions and mode switches remain interactive. Composer edits are unsent preferences, so selecting +Always Approve in the input does not itself change an active session. ### ACP start concurrency diff --git a/packages/acp-extension-grok b/packages/acp-extension-grok index f3f59e1a4..f373cf28e 160000 --- a/packages/acp-extension-grok +++ b/packages/acp-extension-grok @@ -1 +1 @@ -Subproject commit f3f59e1a4528e5e201b24eccb4b3548987bbcc67 +Subproject commit f373cf28e8313286f47e86ea1d8597e8738e396e diff --git a/packages/shared/src/ai.ts b/packages/shared/src/ai.ts index ca0817b49..db13a311e 100644 --- a/packages/shared/src/ai.ts +++ b/packages/shared/src/ai.ts @@ -819,11 +819,6 @@ const GROK_STATIC_CONFIG_OPTIONS: AcpConfigOptionSummary[] = [ name: 'Ask Every Time', description: 'Request approval before protected actions', }, - { - value: 'auto', - name: 'Auto', - description: 'Let Grok decide when approval is required (experimental)', - }, { value: 'always-approve', name: 'Always Approve', diff --git a/packages/shared/tests/ai-grok.test.ts b/packages/shared/tests/ai-grok.test.ts index f1b4d4614..ae45b564e 100644 --- a/packages/shared/tests/ai-grok.test.ts +++ b/packages/shared/tests/ai-grok.test.ts @@ -43,7 +43,6 @@ describe('builtin Grok shared contract', () => { expect(capabilities?.configOptions[0]?.type).toBe('boolean'); expect(capabilities?.configOptions[1]?.options.map((option) => option.value)).toEqual([ 'ask', - 'auto', 'always-approve', ]); expect(capabilities?.configOptions[2]?.currentValue).toBe('grok-4.6'); diff --git a/specs/grok-permission-fallback.zh.md b/specs/grok-permission-fallback.zh.md new file mode 100644 index 000000000..0602e1879 --- /dev/null +++ b/specs/grok-permission-fallback.zh.md @@ -0,0 +1,47 @@ +# Grok ACP 权限兜底 + +Status: draft +Translation: pending + +## 场景与意图 + +用户选择 Always Approve（YOLO）后，官方 Grok 仍可能发送工具权限请求。 +Grok ACP 扩展应直接处理这些请求，避免客户端显示需要用户批准的中间状态。 + +## 权限模式 + +- Grok 扩展及 Lody 静态能力只提供 Ask、Always Approve，不再提供 Auto。 +- 恢复旧会话配置时，原 Auto 值按 Ask 处理；不得转换为 Always Approve。 +- 运行中的配置请求若选择 Auto，应返回不支持，保持之前的模式。 +- 发送已支持权限选择时，明确关闭官方 auto mode；运行中仍使用官方通知入口。 +- 输入框选择继续遵循现有的提交后生效语义。本改动不增加活动回合实时配置入口。 + +## YOLO 自动回应 + +- 对已知会话，扩展按该会话所属客户端已接受的权限模式判断是否为 YOLO。 +- 对新的标准 `session/request_permission` 请求，优先选择 ACP kind 为 + `allow_once` 的选项；若没有，则选择 `allow_always`。 +- 只选择请求提供的有效字符串 optionId，依据 kind 判断允许，不能按标签或 id + 中是否包含英文 allow 来猜测权限。 +- 将 `selected` outcome 直接返回官方运行时，不把同一个请求转发给客户端。 +- `allow_always` 可能在官方运行时保存持久授权，这是仅有该允许选项时的兜底语义。 +- 请求没有可用允许选项、会话未知、模式为 Ask 或属于用户问题、模式切换审批时，保留交互。 + 标准 elicitation 不参与自动批准。 +- 请求 id 必须在各方向独立处理，不能因反向请求 id 相同而消费客户端的待回应请求。 +- 已经转发给客户端的请求继续由客户端负责，本改动不抢答这些请求。 + +## 记录与边界 + +扩展自动回应的请求不会创建 Lody 的 permissionRequest/outcome 历史条目。 +普通工具执行更新仍正常转发。Lody 保留对旧扩展及已转发请求的客户端兼容处理， +该兼容处理仍只选择 `allow_once`。 + +扩展接受的权限选择不是官方运行时状态确认。此兜底不能绕过运行时直接拒绝的操作， +也不改变其他 Provider 的权限行为。 + +## 实现证据 + +- [扩展](../packages/acp-extension-grok/src/proxy.js) 与 + [测试](../packages/acp-extension-grok/test/proxy.test.js)。 +- [静态能力](../packages/shared/src/ai.ts)。 +- [实现记录](../.agents/notes/implemented/bug-fix/2026-09-08-grok-acp-permission-fallback.zh.md)。 From 792a56ae0f75d47e29d9547ac01b830ae77c13a2 Mon Sep 17 00:00:00 2001 From: Leeeon233 Date: Wed, 9 Sep 2026 09:25:43 +0800 Subject: [PATCH 2/3] docs: link Grok permission fallback pull requests Model: gpt-6 --- .../bug-fix/2026-09-08-grok-acp-permission-fallback.zh.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.agents/notes/implemented/bug-fix/2026-09-08-grok-acp-permission-fallback.zh.md b/.agents/notes/implemented/bug-fix/2026-09-08-grok-acp-permission-fallback.zh.md index be09bc2b0..a607b68f8 100644 --- a/.agents/notes/implemented/bug-fix/2026-09-08-grok-acp-permission-fallback.zh.md +++ b/.agents/notes/implemented/bug-fix/2026-09-08-grok-acp-permission-fallback.zh.md @@ -45,5 +45,5 @@ Translation: pending `tsgo`、`prettier` 缺失处停止。定向检查通过；没有完整应用或真实模型回合验证。 本次修改分为 [Grok 扩展 PR #15](https://github.com/LodyAI/acp-extension-grok/pull/15) -和依赖 #503 的 Lody 集成 PR。 +和依赖 #503 的 [Lody 集成 PR #533](https://github.com/LodyAI/Lody/pull/533)。 英文翻译待补。 From 817082a6b18e3464ccb63ad4fb787bc01e34e085 Mon Sep 17 00:00:00 2001 From: Leeeon233 Date: Wed, 9 Sep 2026 09:38:04 +0800 Subject: [PATCH 3/3] chore: pin merged Grok permission fallback Model: gpt-6 --- packages/acp-extension-grok | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/acp-extension-grok b/packages/acp-extension-grok index f373cf28e..c962338e3 160000 --- a/packages/acp-extension-grok +++ b/packages/acp-extension-grok @@ -1 +1 @@ -Subproject commit f373cf28e8313286f47e86ea1d8597e8738e396e +Subproject commit c962338e3e6e68858e0bf92e9671a84b9a07e055