Skip to content

修复共享 Skill 发现与启停 - #3045

Merged
BigPizzaV3 merged 5 commits into
BigPizzaV3:mainfrom
130040167:codex/skill-shared-discovery-review
Nov 12, 2026
Merged

BigPizzaV3 merged 5 commits into
BigPizzaV3:mainfrom
130040167:codex/skill-shared-discovery-review

Conversation

@130040167

@130040167 130040167 commented Nov 11, 2026 •

Copy link
Copy Markdown
Contributor

问题

用户级共享 Skill 没有出现在管理器里,重复启用时可能复制出额外目录;原生配置中的停用规则也没有反映到列表。

修改

  • 发现共享目录及已配置 Agent 目录中的安装和有效链接,展示实际位置与 Codex 启用状态。
  • 按 Codex 原生语义处理相对路径及同时包含名称、路径的规则;共享或本地目录通过原生配置启停。
  • 其他 Agent 优先链接共享原件;Windows 复制回退副本可停用后重新启用以取得当前内容,用户自行创建的链接保持不动。
  • 共享目录与 Codex 目录指向同一位置时沿用普通托管行为。重新安装已停用的 Skill 会恢复启用,更新已有 Skill 则保留停用状态。
  • 新安装的目标规则无法识别时保留原配置并完成安装,库存显示状态未知;真实配置读写失败仍会报告,不覆盖现有文件。
  • 缓存页面库存并合并并发刷新。拓展只读数据 installedSkills.enabled 在状态未知时为 null,并提供 statusError;相关接口说明在 EXTENSIONS.md 和类型定义中。

拆分关系

本 PR 是第一项。来源关联见 #3056,普通 GitHub 原位更新与备份见 #3057,按此顺序审核和合入;后两项在前置项合入前暂时包含前置差异,描述中提供各自的独立对照。

验证

  • 基于更新后的上游主线,Windows 隔离环境 Skill 核心测试 162 项通过、1 项因缺少第二磁盘忽略;新增回归覆盖未知规则、无法识别名称以及文件读取错误。
  • 包含三个增量的当前分支:Skill 核心测试 250 项通过、5 项按环境忽略;生命周期 10 项、拓展只读接口 8 项通过。
  • 此前 Windows Sandbox 使用上一版管理器核心代码停用共享 Skill 后,原生 Codex skills/list 返回 enabled: false 且原件保留;另验证相对路径、路径大小写、junction 和双字段规则。
  • 远端平台检查以当前提交的运行结果为准。

@BigPizzaV3

Copy link
Copy Markdown
Owner

感谢拆分,这次范围很清楚,没有夹带 REA 或来源关联的内容。我们用 codex-cli 0.149.1 实测过 [[skills.config]]:路径指向 SKILL.md、多条规则匹配时最后一条生效、~/.agents/skills 会被扫描,这几点和实现一致。不再搬动用户自建目录、只删除指向受控源的链接,这两处改动也比原来安全。

合并前还请处理以下几点:

  1. Codex 能接受的配置会让整个 Skills 列表读取失败。 read_native_skill_config 遇到相对 path,或同时写了 name 和 path 的条目会直接报错,list_installed_skills 和扩展的 installedSkills 都跟着失败,没用共享 Skill 的用户也会受影响。实测 Codex 会按 config.toml 所在目录解析相对路径,同时写两个字段时也不报错。建议相对路径按 CODEX_HOME 解析;单条无法识别的规则只把相关 Skill 标成「状态未知」,不要让整份库存失败。
  2. 共享 Skill 启用到 Claude/Grok 后会卡在旧快照上。 目前会先复制一份受控源再链过去。共享目录更新后,Grok 看到的仍是旧内容,再启用到其他 Agent 会提示「内容不同」,卸载又被共享保护拦下,界面上没有办法恢复。能否让其他 Agent 直接链接到共享目录,或者给出同步/清理这份快照的入口?
  3. ~/.codex/skills 和 ~/.agents/skills 是同一目录时(互相软链),所有受控 Skill 都被当成共享,无法更新也无法卸载。建议构造时比较两者 canonicalize 后的路径,相同就不启用共享逻辑。
  4. Windows 复制回退的副本停用后会留下 enabled = false。 现在停用改为写这条规则;之后卸载再重装同一 id,这条规则还在,重装后在 Codex 里仍是停用。请在卸载时清掉对应规则,或在安装启用时重置为启用,并在 PR 描述里说明这项行为变化。
  5. 小问题:文件原本没有 [skills] 时会多写一个空的 [skills] 表头;installedSkills.enabled 可能为 null,这对扩展作者算接口变化,麻烦在 CHANGELOG 里注明。

第 1 到第 4 项请各补一个测试。另外麻烦在 Windows 真机上验证一次:停用共享 Skill 之后,Codex 确实不再加载它(路径大小写、盘符形式都对得上)。谢谢!

@BigPizzaV3 BigPizzaV3 mentioned this pull request Nov 11, 2026
2 tasks done
@130040167

Copy link
Copy Markdown
Contributor Author

感谢详细复核,已在 a2c4729d 处理:

  1. 相对路径按 CODEX_HOME 解析;同一条规则的名称和路径同时存在时要求两者都匹配。不能识别的单条规则只使可定位的对应 Skill 状态未知,不再使整份清单失败。
  2. 新启用到其他 Agent 时优先使用共享原件,记录由管理器创建的链接或复制副本;旧受控链接可先停用,再启用到共享原件。Windows 复制回退的副本停用后重新启用可取得当前共享内容。
  3. 两个根目录指向同一物理目录时不启用共享目录特殊处理,回归覆盖更新和卸载。
  4. 新安装或重装时重置该安装位置的原生停用规则;更新现有安装仍保留停用状态,配置及状态写入失败会回滚。
  5. 新建配置不再增加空 [skills] 表头,并在 CHANGELOG 中注明拓展 installedSkills.enabled 可能为 null。

补充了对应回归。在 Windows 宿主的隔离 Sandbox 中,使用本次管理器核心代码停用共享 Skill 后,原生 Codex skills/list 返回 enabled: false,原件保留;还验证了相对路径、大小写和 junction。此结果是原生接口联动验证,未将它表述为管理页交互验收。最新三平台检查已重新触发。

@130040167

Copy link
Copy Markdown
Contributor Author

补充一下 a2c4729d 的检查结果:Windows 和 macOS 构建通过。Linux 在安装系统依赖时无法解析 archive.ubuntu.com,还没有进入项目编译。

我尝试重跑失败任务,但当前账号没有上游仓库的 Actions 重跑权限。麻烦有权限时重跑一下 Linux job,谢谢!

@130040167

Copy link
Copy Markdown
Contributor Author

Linux 任务重跑后已通过,当前 Windows、macOS 和 Linux 检查均为通过。感谢协助!

@BigPizzaV3

Copy link
Copy Markdown
Owner

感谢这一轮修改,逐条核对过了:相对路径和双字段规则只影响对应 Skill,其他 Agent 改为链接共享原件并记录自建副本,同目录时不启用共享逻辑,重装时重置停用规则并支持回滚,空 [skills] 表头也不再写入。Linux CI 我们已经帮你重跑了。

还有两处麻烦再看一下:

  1. CHANGELOG 位置:这条「共享 Skill 的发现与启停」现在加在 2.6.3 一节里,main 上已经发布到 2.6.5,合并后会悄悄落进已发布版本的说明(git merge-tree 没有冲突,所以不会提醒)。麻烦 rebase 到最新 main,把它移到新的版本节里,或者先不写 CHANGELOG,发版时我们来补。
  2. 安装时重置停用规则不要让安装失败:现在新装会调用 set_native_skill_paths(..., true),其中 config.enabled(...)?(skills.rs:731)遇到状态未知的规则就报错。比如 config.toml 里有 [[skills.config]] name = 'alpha' 加 enabled = 'yes',安装 alpha 会整体失败回滚,还会留下 .codex-plus-recovery-* 目录,报错里「回滚检查:」后面是空的。这和第 1 点「单条规则不影响整体」的思路不一致。建议这一步遇到读取或识别失败时跳过重置、继续安装(或者直接写一条 enabled = true 覆盖),再补一个用例。

谢谢!

@130040167

Copy link
Copy Markdown
Contributor Author

感谢继续复核,已在 89c8954d 处理:

  1. 已 rebase 到当时最新的 main,移除了写入已发布版本的 CHANGELOG 条目;接口中的状态未知行为仍在 EXTENSIONS.md 和类型定义中说明。
  2. 新安装时,如果目标规则的启用值或名称无法识别,就保留原配置并跳过该位置的重置,安装继续完成;库存会报告状态未知。手动启停仍会报告未知状态,配置文件的真实读写失败也不会被隐藏。

新增回归覆盖 enabled = 'yes' 和无法识别的名称:安装及记录保留、配置不变、状态未知,且不会创建恢复目录。基于新主线的 Skill 核心测试为 161 通过、1 项因缺少第二磁盘忽略。

后续已按依赖分别提交来源关联 #3056 和普通 GitHub 更新与备份 #3057;由于上游没有中间基准分支,两项先以草稿形式提交,并在描述中提供各自的独立增量对照。

@130040167

Copy link
Copy Markdown
Contributor Author

补充:在 039553d3 收紧了名称解析的错误边界。只有不支持的名称语法会跳过安装时重置;实际文件读取错误仍会返回,避免静默掩盖。新增读取失败回归,当前第一项 Skill 核心测试为 162 通过、1 项因缺少第二磁盘忽略。该修复也已带入后续两个依赖分支。

@130040167

Copy link
Copy Markdown
Contributor Author

补充:#3056 和 #3057 已设为可审核状态;两项仍按描述中的依赖顺序合入,独立差异链接保持不变。

@BigPizzaV3
BigPizzaV3 merged commit 3974be8 into BigPizzaV3:main Nov 12, 2026
@BigPizzaV3

Copy link
Copy Markdown
Owner

感谢!CHANGELOG 已移出已发布版本,安装时遇到无法识别的原生规则会跳过重置并报告状态未知、真实读取错误仍返回,三条新回归和 skills 的 181 项测试本地通过。已合入 main,随下个版本发布。#3056、#3057 我们接着按依赖顺序看。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants