多仓库协作：codex-plugin-cc的workspace根与项目配置隔离机制

多仓库协作codex-plugin-cc的workspace根与项目配置隔离机制【免费下载链接】codex-plugin-ccUse Codex from Claude Code to review code or delegate tasks.项目地址: https://gitcode.com/GitHub_Trending/co/codex-plugin-cc用 codex-plugin-cc 在 Claude Code 中同时处理多个仓库时如何避免不同项目的任务状态互相串台答案就藏在它的 **workspace 根workspace root**机制里插件以 Git 仓库根目录为锚点为每个仓库生成独立的状态目录再配合.codex/config.toml的项目级配置隔离实现一个仓库一份状态、一套配置的多仓库协作体验 为什么多仓库协作需要隔离/codex:review、/codex:rescue等命令都会产生后台任务插件需要记住任务在跑什么、进行到哪一步、最终结果是什么。如果这些状态全局共享就会出现典型的多仓库冲突在仓库 A 跑审查任务切到仓库 B 执行/codex:status却看到 A 的任务列表仓库 A 的 review gate 设置泄露到仓库 B任务日志和结果文件找不到归属越积越多无法清理codex-plugin-cc 的解法可以概括为一句话所有状态都围绕workspace 根来寻址而 workspace 根就是 Git 仓库根。workspace 根如何确定Git 仓库根是锚点入口函数resolveWorkspaceRoot只有短短几行先尝试把当前目录解析为 Git 仓库根失败则退回当前目录兜底。判定逻辑plugins/codex/scripts/lib/workspace.mjs底层依赖git rev-parse --show-toplevel命令plugins/codex/scripts/lib/git.mjs这意味着一个很直观的行为你在仓库的哪个子目录启动 Claude Code都不会影响状态归属——src/下启动和仓库根目录启动解析出的 workspace 根是同一个。只有当目录不属于任何 Git 仓库时才会以当前目录cwd作为兜底根。状态隔离每个仓库一个独立状态目录拿到 workspace 根之后resolveStateDir会推导出一个仓库专属的状态目录核心步骤如下对仓库根路径做规范化realpathSync.native避免软链接、相对路径导致同一仓库被算成两个取目录名生成可读的slug非法字符替换为-对规范化后的根路径计算SHA-256 哈希前 16 位防止不同机器上同名仓库目录撞车最终目录名形如my-repo-a1b2c3d4e5f60718关键实现plugins/codex/scripts/lib/state.mjs行为验证含目录命名规则断言tests/state.test.mjs状态目录的位置也有讲究若设置了环境变量CLAUDE_PLUGIN_DATA状态放在该目录/state/slug-hash/否则回退到系统临时目录下的codex-companion/见 state.mjs 第 9-13 行常量定义这个设计带来两个好处仓库工作区保持干净不会在仓库里生成垃圾文件且同一台机器上任意多仓库互不干扰——各自读写自己的state.json和jobs/目录。目录内每个任务还有独立的 JSON 与日志文件jobId.json/jobId.log由 plugins/codex/scripts/lib/tracked-jobs.mjs 创建。为防止无限膨胀saveState只保留最近50 个任务MAX_JOBS 50被淘汰任务的 JSON 与日志文件会被同步清理规则见 pruneJobs 与 saveState。任务追踪/codex:status 只看见当前仓库隔离机制在执行层面是如何生效的以任务生命周期为例任务启动时runTrackedJob以job.workspaceRoot为键写入运行状态tracked-jobs.mjs/codex:status由buildStatusSnapshot汇总先resolveWorkspaceRoot锁定当前仓库再读取该仓库名下的任务列表job-control.mjs所以当你从仓库 A 切到仓库 B 后执行/codex:status看到的永远是 B 的任务——这正是 README 中running and recent Codex jobsfor the current repository承诺的语义。还有一个更细粒度的隔离维度会话。任务创建时会从环境变量CODEX_COMPANION_SESSION_ID记录所属 Claude 会话tracked-jobs.mjs 第 6 行/codex:status、/codex:cancel等命令会优先按当前会话过滤任务见 filterJobsForCurrentSession。也就是说隔离是仓库 × 会话的双层结构 项目配置隔离两层 config.toml 各司其职状态隔离解决任务不打架配置隔离解决各仓库用各仓库的模型与参数。插件复用了 Codex 自身的两级配置体系详见 README.md 的 Common Configurations 一节层级位置作用用户级~/.codex/config.toml所有仓库的默认模型、推理强度等项目级仓库根的.codex/config.toml仅对当前仓库生效的覆盖项例如希望某个项目固定使用gpt-5.4-mini模型model gpt-5.4-mini model_reasoning_effort high两个值得注意的边界项目级配置仅在项目被 Codex 信任时才会加载防止陌生仓库里的配置文件改变你的行为插件使用的是本机同一份 Codex 运行时你已有的登录态、API key、openai_base_url等设置全部原样生效快速自检清单在多仓库环境验证隔离是否正常工作可以按顺序检查✅ 两个不同仓库分别跑/codex:review --background/codex:status各自只列出本仓库任务✅ 在仓库 A 执行/codex:setup --enable-review-gate切到仓库 B 确认 gate 并未开启✅ 在仓库 B 根目录放置.codex/config.toml指定独立模型跑一次任务确认配置覆盖生效✅ 检查系统临时目录或CLAUDE_PLUGIN_DATA/state下存在仓库名-16位哈希形式的独立状态目录✅ 连续提交 50 个以上任务后旧任务的文件被自动清理目录不再无限增长小结codex-plugin-cc 用一条清晰的规则支撑多仓库协作Git 仓库根 workspace 根 状态与配置的隔离边界。状态侧通过slug 哈希目录把任务索引、日志、配置各归其位配置侧沿用 Codex 用户级/项目级两层config.toml项目级配置以信任为前提加载。理解这套机制后你可以放心地在同一台机器上并行推进多个仓库的代码审查与任务委派而不必担心状态串台或配置污染。【免费下载链接】codex-plugin-ccUse Codex from Claude Code to review code or delegate tasks.项目地址: https://gitcode.com/GitHub_Trending/co/codex-plugin-cc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考