人工智能AI 插件代码智能体【免费下载链接】codex-plugin-ccUse Codex from Claude Code to review code or delegate tasks.项目地址https://gitcode.com/GitHub_Trending/co/codex-plugin-cc点击查看免费下载/codex:review是 codex-plugin-cc 插件提供的只读代码审查命令它绕过自定义提示词直接调用你本机 Codex CLI 的内置评审器built-in reviewer让你在 Claude Code 工作流中拿到与在 Codex 里执行/review完全一致的审查质量。读完本文你将掌握该命令的完整参数语义--wait、--background、--base、--scope、前台/后台两种执行流程、审查目标working-tree / branch的自动判定规则以及从 slash 命令到 Codex app-server 的底层调用链能够在自己项目中稳定地编排提交前 Codex 审查这一环节。命令定位review-only 的共享内置评审器/codex:review的定义位于 plugins/codex/commands/review.md其 YAML frontmatter 明确声明了三条关键约束disable-model-invocation: true禁止模型直接以对话方式调用必须走 slash 命令路由allowed-tools: Read, Glob, Grep, Bash(node:*), Bash(git:*), AskUserQuestion执行期间只允许只读工具Read/Glob/Grep、node 与 git 相关 Bash以及一次性的询问工具argument-hint: [--wait|--background] [--base ref] [--scope auto|working-tree|branch]向用户暴露的合法参数形态。该命令的核心定位是review-only文档明确要求不要修复问题、不要打补丁、不要暗示你即将做出改动你的唯一职责是运行审查并把 Codex 的输出逐字verbatim返回给用户。这意味着/codex:review是一条安全的、可随时放入 CI 前或提交前流程的只读命令绝不会触碰工作区。它与/codex:adversarial-review见 adversarial-review.md形成互补维度/codex:review/codex:adversarial-review评审器Codex 内置评审器native插件用提示词模板驱动的对抗式评审可引导性不可引导不接受自定义 focus 文本可引导flags 后可直接追加 focus text目标选择相同的 target 解析含--base相同的 target 解析含--base典型场景未提交改动、分支对比main挑战某个设计决策、风险区域auth、数据丢失、回滚、竞态参数全集--wait / --background / --base / --scope 的语义命令的完整语法为/codex:review [--wait|--background] [--base ref] [--scope auto|working-tree|branch]各参数的真实行为从 codex-companion.mjs 的handleReviewCommand约 L712可看到严格对应--base、--scope、--model、--cwd被解析为值参数value options--background、--wait、--json被解析为布尔参数位置参数positionals被合并为focusText——但原生 review 不接受任何 focus 文本。参数类型作用--wait布尔强制前台运行不询问用户直接阻塞等待审查结果--background布尔强制后台运行立即返回进度由/codex:status查询--base ref值指定基准分支如main切换为分支差异审查--scope auto\|working-tree\|branch值显式指定审查目标范围默认auto--model model值覆盖本次审查使用的模型可选--cwd path值指定工作目录可选底层参数解析由 args.mjs 的parseArgs完成支持--keyvalue内联值与短选项别名如-m映射到--model、--透传、引号包裹与反斜杠转义splitRawArgumentString。例如--scopeworking-tree与--scope working-tree等价。一个关键差异--wait/--background由谁处理文档特别强调不要自己剥离--wait或--background原始参数必须原样传给配套脚本。真正让后台运行脱离的是 Claude Code 的Bash(..., run_in_background: true)调用而不是脚本本身——脚本只是负责解析并执行审查。这也解释了为什么命令文档要求不要额外添加审查指令、不要改写用户意图。执行模式规则前台、后台还是先问一次命令文档定义了严格的分流逻辑review.md 的 Execution mode rules原始参数包含--wait→不询问前台运行原始参数包含--background→不询问以 Claude 后台任务运行其他情况 →先估计审查规模再决定询问。审查规模的估计方法规模估计完全基于只读 git 命令对应文档给出的三条指令working-tree 审查先跑git status --short --untracked-filesall再同时检查git diff --shortstat --cached与git diff --shortstatbase-branch 审查使用git diff --shortstat base...HEAD未跟踪文件untracked视为可审查的工作即使git diff --shortstat为空也不能漏掉只有相关工作区状态为空、或显式分支差异为空时才能下结论没有可审查内容仅当审查明显很小总计约 1-2 个文件、且没有目录级大改动的迹象时才推荐等待其余情况一律推荐后台拿不准时宁可运行审查也不要宣布无内容可审。在源码侧git.mjs 的getWorkingTreeState约 L121用git diff --cached --name-only、git diff --name-only、git ls-files --others --exclude-standard分别收集暂存、未暂存、未跟踪文件三组并集非空即判定isDirty——与文档把 untracked 视为可审查工作的规则完全吻合。恰好询问一次AskUserQuestion在需要询问的情况下使用AskUserQuestion恰好一次提供两个选项且推荐项在前、标签后缀(Recommended)Wait for resultsRun in background这是命令文档对执行代理Claude Code 模型的硬性指令确保交互路径可预期要么阻塞等结果要么转后台不存在第三种静默行为。审查目标解析auto 模式下如何自动选择无论是否显式传--scope最终都会落到resolveReviewTargetgit.mjs 约 L134的判定逻辑。结合命令文档与源码目标解析规则如下显式传--base ref→ 直接进入branch模式标签为branch diff against baseRef显式传--scope working-tree→ 进入working-tree模式显式传--scope branch→ 自动探测默认分支detectDefaultBranch依次尝试refs/remotes/origin/HEAD、main、master、trunk再进入branch模式--scope为非法值→ 抛错提示使用auto/working-tree/branch或--base ref默认auto工作区有改动staged/unstaged/untracked 任一非空→working-tree否则自动探测默认分支 →branch。分支审查的差异计算在buildBranchComparison约 L68先git merge-base HEAD baseRef求合并基点用mergeBase..HEAD作为提交区间与 diff 区间用baseRef...HEAD作为审查标签区间。也就是说分支审查只针对你分支相对基准分支引入的提交不包含基准分支上别人的改动。需要特别留意的是原生 review 的目标被映射为两类buildNativeReviewTargetcodex-companion.mjs 约 L259working-tree模式 →{ type: uncommittedChanges }branch模式 →{ type: baseBranch, branch: baseRef }其余目标会被validateNativeReviewRequest拒绝并提示改用/codex:adversarial-review。这与命令文档的声明一致/codex:review是 native-review only不支持 staged-only 审查、unstaged-only 审查或额外 focus 文本——需要自定义审查指令或更强的对抗性框架时应切换到/codex:adversarial-review。前台流程一条命令原样返回 stdout前台执行的完整命令来自 review.md 的 Foreground flownode ${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs review $ARGUMENTS其中CLAUDE_PLUGIN_ROOT由 Claude Code 注入指向插件根目录$ARGUMENTS是用户传给 slash 命令的原始参数字符串。命令文档对输出处理有三条铁律返回命令 stdout逐字原样as-is前后不做改写、总结或评论不修复输出中提到的任何问题。从源码看handleReviewcodex-companion.mjs 约 L755会创建一条jobClass: review的作业记录createCompanionJob前缀review再经runForegroundCommand执行executeReviewRun最终把rendered结果直接写到 stdout。渲染层 render.mjs 的renderNativeReviewResult约 L288只是把 Codex 的审查文本封装成 Markdown 标题# Codex Review与Target:行随后原样嵌入 stdout 正文并附上 reasoning summary 与 stderr——这保证了逐字返回 Codex 输出这一约束在执行层被严格落地。后台流程run_in_background 与状态轮询后台执行在命令文档中给出的是 TypeScript 形态的 Bash 调用Bash({ command: node ${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs review $ARGUMENTS, description: Codex review, run_in_background: true })配套行为约束同样明确本回合不得调用BashOutput也不得等待完成启动后立即告知用户Codex review started in the background. Check /codex:status for progress.这正好与配套的状态命令闭环status.md 让/codex:status [job-id]展示当前仓库运行中/最近的 Codex 作业无 job-id 时渲染为紧凑 Markdown 表格含 job ID、kind、status、phase、耗时、summary 与后续命令作业完成后可用 result.md 的/codex:result [job-id]查看存储的完整输出不再需要时可参考 cancel.md 的/codex:cancel [job-id]中断运行中的任务。一个典型的一键三连/codex:review --background /codex:status /codex:result底层调用链从 slash 命令到 Codex app-server 的 review/start理解这条命令的可靠性需要看它最终如何驱动 Codex。executeReviewRuncodex-companion.mjs 约 L358的流程为ensureCodexAvailable(cwd)检查全局codex二进制存在且支持app-server高级运行时codex.mjs 的getCodexAvailability约 L886ensureGitRepository(cwd)git rev-parse --show-toplevel确认当前目录在 Git 仓库内resolveReviewTarget按上文规则解析目标validateNativeReviewRequest(target, focusText)拒绝任何 focus 文本、拒绝非原生目标runAppServerReview(cwd, { target, model, onProgress })真正发起审查。runAppServerReviewcodex.mjs 约 L1002是核心它通过withAppServer建立与 Codex app-server 的客户端连接然后thread/start以sandbox: read-only、ephemeral: true启动一个临时线程model 可选传入可被覆盖review/start向该线程发起内置评审请求delivery: inline默认target即前面解析出的uncommittedChanges或baseBranch目标captureTurn通过 app-server 通知流捕获整个 turn——enteredReviewModeReviewer started、exitedReviewMode捕获item.review作为reviewText、reasoning汇总推理摘要等事件都会被记录返回reviewText、reasoningSummary、threadId、turnId、status等交由上层渲染。关键设计点是只读双保险命令层禁止修改review-only 约束app-server 线程层也用sandbox: read-only兜底审查过程不可能写回工作区。同时withAppServer还实现了 broker 降级重连当共享会话broker繁忙BROKER_BUSY_RPC_CODE或不可达时自动回退到直接启动一个 app-server 实例保证审查不因共享运行时忙碌而失败。另外值得一提的是--model覆盖能力handleReviewCommand支持--model别名-m并经由normalizeRequestedModel把spark映射为gpt-5.3-codex-spark。不传时模型与推理力度完全由你的 Codex 配置决定见下节。如何配置审查使用的模型与推理力度/codex:review复用你本机 Codex CLI 的全部配置不引入独立运行时。想调整默认模型或 reasoning effort只需在项目根目录的.codex/config.toml或用户级~/.codex/config.toml中设置model gpt-5.4-mini model_reasoning_effort high配置加载顺序为用户级~/.codex/config.toml→ 项目级.codex/config.toml仅在项目受信任时加载。这样你在 Claude Code 里敲/codex:review时Codex 会使用与命令行直接使用完全一致的模型与推理策略审查质量与在 Codex TUI 中执行/review一致。实战建议与边界条件基于命令文档与源码实现总结几条可直接套用的实战经验多文件改动优先--background多文件审查耗时较长后台运行后配合/codex:status轮询、/codex:result取最终输出是最省心的组合提交前对比基准/codex:review --base main只审查你分支相对main引入的提交适合 PR 前的定向检查有未跟踪文件时别急新文件会被计入可审查工作ls-files --others会被收集审查前记得确认这些确实是你要评审的内容需要引导时切换命令想针对 auth、数据丢失、回滚、竞态等风险区域做定向挑战或想给审查加 focus 文本请改用/codex:adversarial-reviewread-only 保证命令层约束 sandbox: read-only双保险审查过程不会修改任何文件可以放心纳入常规提交流程。总结/codex:review把 Codex 的原生评审器以一条 slash 命令的形式接入 Claude Code参数层支持前台/后台/自动询问与--base/--scope目标控制执行层严格保持 review-only 与 stdout 逐字返回实现层则通过 app-server 的review/startRPC 以只读沙箱驱动 Codex 内置评审器。配合/codex:status、/codex:result、/codex:cancel你可以把提交前 Codex 审查编排成完整、可中断、可回溯的开发闭环——而这一切都复用于你本机已有的 Codex 安装、登录态与配置。赞分享人工智能AI 插件代码智能体【免费下载链接】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 的 /codex:status 命令完全指南在 Claude Code 中查看与跟踪 Codex 后台任务codex plugin cc 的 /codex:status 命令完全指南在 Claude Code 中查看与跟踪 Codex 后台任务 导读 /codex人工智能AI 插件代码智能体garak unsafe_content 检测器全解毒性模型与脏词表如何识别 LLM 不安全输出garak unsafe_content 检测器全解毒性模型与脏词表如何识别 LLM 不安全输出 导读 garak the LLM vulnerabilit人工智能AI 插件代码智能体CleanRL 完整上手指南5 分钟跑通单文件强化学习实验CleanRL 完整上手指南5 分钟跑通单文件强化学习实验 CleanRL 是一个深度强化学习库把 PPO、DQN、SAC 等主流算法以高质量单文件实现的方人工智能AI 插件代码智能体上一篇Erlang/OTP 30 移除计划详解Guard 类型测试别名、分布式协议与加密组件弃用清单下一篇Photoshop图层批量导出终极指南如何将工作效率提升90倍创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
在 Claude Code 中一键运行 Codex 原生代码审查：codex-plugin-cc 的 /codex:review 命令实战指南
人工智能AI 插件代码智能体【免费下载链接】codex-plugin-ccUse Codex from Claude Code to review code or delegate tasks.项目地址https://gitcode.com/GitHub_Trending/co/codex-plugin-cc点击查看免费下载/codex:review是 codex-plugin-cc 插件提供的只读代码审查命令它绕过自定义提示词直接调用你本机 Codex CLI 的内置评审器built-in reviewer让你在 Claude Code 工作流中拿到与在 Codex 里执行/review完全一致的审查质量。读完本文你将掌握该命令的完整参数语义--wait、--background、--base、--scope、前台/后台两种执行流程、审查目标working-tree / branch的自动判定规则以及从 slash 命令到 Codex app-server 的底层调用链能够在自己项目中稳定地编排提交前 Codex 审查这一环节。命令定位review-only 的共享内置评审器/codex:review的定义位于 plugins/codex/commands/review.md其 YAML frontmatter 明确声明了三条关键约束disable-model-invocation: true禁止模型直接以对话方式调用必须走 slash 命令路由allowed-tools: Read, Glob, Grep, Bash(node:*), Bash(git:*), AskUserQuestion执行期间只允许只读工具Read/Glob/Grep、node 与 git 相关 Bash以及一次性的询问工具argument-hint: [--wait|--background] [--base ref] [--scope auto|working-tree|branch]向用户暴露的合法参数形态。该命令的核心定位是review-only文档明确要求不要修复问题、不要打补丁、不要暗示你即将做出改动你的唯一职责是运行审查并把 Codex 的输出逐字verbatim返回给用户。这意味着/codex:review是一条安全的、可随时放入 CI 前或提交前流程的只读命令绝不会触碰工作区。它与/codex:adversarial-review见 adversarial-review.md形成互补维度/codex:review/codex:adversarial-review评审器Codex 内置评审器native插件用提示词模板驱动的对抗式评审可引导性不可引导不接受自定义 focus 文本可引导flags 后可直接追加 focus text目标选择相同的 target 解析含--base相同的 target 解析含--base典型场景未提交改动、分支对比main挑战某个设计决策、风险区域auth、数据丢失、回滚、竞态参数全集--wait / --background / --base / --scope 的语义命令的完整语法为/codex:review [--wait|--background] [--base ref] [--scope auto|working-tree|branch]各参数的真实行为从 codex-companion.mjs 的handleReviewCommand约 L712可看到严格对应--base、--scope、--model、--cwd被解析为值参数value options--background、--wait、--json被解析为布尔参数位置参数positionals被合并为focusText——但原生 review 不接受任何 focus 文本。参数类型作用--wait布尔强制前台运行不询问用户直接阻塞等待审查结果--background布尔强制后台运行立即返回进度由/codex:status查询--base ref值指定基准分支如main切换为分支差异审查--scope auto\|working-tree\|branch值显式指定审查目标范围默认auto--model model值覆盖本次审查使用的模型可选--cwd path值指定工作目录可选底层参数解析由 args.mjs 的parseArgs完成支持--keyvalue内联值与短选项别名如-m映射到--model、--透传、引号包裹与反斜杠转义splitRawArgumentString。例如--scopeworking-tree与--scope working-tree等价。一个关键差异--wait/--background由谁处理文档特别强调不要自己剥离--wait或--background原始参数必须原样传给配套脚本。真正让后台运行脱离的是 Claude Code 的Bash(..., run_in_background: true)调用而不是脚本本身——脚本只是负责解析并执行审查。这也解释了为什么命令文档要求不要额外添加审查指令、不要改写用户意图。执行模式规则前台、后台还是先问一次命令文档定义了严格的分流逻辑review.md 的 Execution mode rules原始参数包含--wait→不询问前台运行原始参数包含--background→不询问以 Claude 后台任务运行其他情况 →先估计审查规模再决定询问。审查规模的估计方法规模估计完全基于只读 git 命令对应文档给出的三条指令working-tree 审查先跑git status --short --untracked-filesall再同时检查git diff --shortstat --cached与git diff --shortstatbase-branch 审查使用git diff --shortstat base...HEAD未跟踪文件untracked视为可审查的工作即使git diff --shortstat为空也不能漏掉只有相关工作区状态为空、或显式分支差异为空时才能下结论没有可审查内容仅当审查明显很小总计约 1-2 个文件、且没有目录级大改动的迹象时才推荐等待其余情况一律推荐后台拿不准时宁可运行审查也不要宣布无内容可审。在源码侧git.mjs 的getWorkingTreeState约 L121用git diff --cached --name-only、git diff --name-only、git ls-files --others --exclude-standard分别收集暂存、未暂存、未跟踪文件三组并集非空即判定isDirty——与文档把 untracked 视为可审查工作的规则完全吻合。恰好询问一次AskUserQuestion在需要询问的情况下使用AskUserQuestion恰好一次提供两个选项且推荐项在前、标签后缀(Recommended)Wait for resultsRun in background这是命令文档对执行代理Claude Code 模型的硬性指令确保交互路径可预期要么阻塞等结果要么转后台不存在第三种静默行为。审查目标解析auto 模式下如何自动选择无论是否显式传--scope最终都会落到resolveReviewTargetgit.mjs 约 L134的判定逻辑。结合命令文档与源码目标解析规则如下显式传--base ref→ 直接进入branch模式标签为branch diff against baseRef显式传--scope working-tree→ 进入working-tree模式显式传--scope branch→ 自动探测默认分支detectDefaultBranch依次尝试refs/remotes/origin/HEAD、main、master、trunk再进入branch模式--scope为非法值→ 抛错提示使用auto/working-tree/branch或--base ref默认auto工作区有改动staged/unstaged/untracked 任一非空→working-tree否则自动探测默认分支 →branch。分支审查的差异计算在buildBranchComparison约 L68先git merge-base HEAD baseRef求合并基点用mergeBase..HEAD作为提交区间与 diff 区间用baseRef...HEAD作为审查标签区间。也就是说分支审查只针对你分支相对基准分支引入的提交不包含基准分支上别人的改动。需要特别留意的是原生 review 的目标被映射为两类buildNativeReviewTargetcodex-companion.mjs 约 L259working-tree模式 →{ type: uncommittedChanges }branch模式 →{ type: baseBranch, branch: baseRef }其余目标会被validateNativeReviewRequest拒绝并提示改用/codex:adversarial-review。这与命令文档的声明一致/codex:review是 native-review only不支持 staged-only 审查、unstaged-only 审查或额外 focus 文本——需要自定义审查指令或更强的对抗性框架时应切换到/codex:adversarial-review。前台流程一条命令原样返回 stdout前台执行的完整命令来自 review.md 的 Foreground flownode ${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs review $ARGUMENTS其中CLAUDE_PLUGIN_ROOT由 Claude Code 注入指向插件根目录$ARGUMENTS是用户传给 slash 命令的原始参数字符串。命令文档对输出处理有三条铁律返回命令 stdout逐字原样as-is前后不做改写、总结或评论不修复输出中提到的任何问题。从源码看handleReviewcodex-companion.mjs 约 L755会创建一条jobClass: review的作业记录createCompanionJob前缀review再经runForegroundCommand执行executeReviewRun最终把rendered结果直接写到 stdout。渲染层 render.mjs 的renderNativeReviewResult约 L288只是把 Codex 的审查文本封装成 Markdown 标题# Codex Review与Target:行随后原样嵌入 stdout 正文并附上 reasoning summary 与 stderr——这保证了逐字返回 Codex 输出这一约束在执行层被严格落地。后台流程run_in_background 与状态轮询后台执行在命令文档中给出的是 TypeScript 形态的 Bash 调用Bash({ command: node ${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs review $ARGUMENTS, description: Codex review, run_in_background: true })配套行为约束同样明确本回合不得调用BashOutput也不得等待完成启动后立即告知用户Codex review started in the background. Check /codex:status for progress.这正好与配套的状态命令闭环status.md 让/codex:status [job-id]展示当前仓库运行中/最近的 Codex 作业无 job-id 时渲染为紧凑 Markdown 表格含 job ID、kind、status、phase、耗时、summary 与后续命令作业完成后可用 result.md 的/codex:result [job-id]查看存储的完整输出不再需要时可参考 cancel.md 的/codex:cancel [job-id]中断运行中的任务。一个典型的一键三连/codex:review --background /codex:status /codex:result底层调用链从 slash 命令到 Codex app-server 的 review/start理解这条命令的可靠性需要看它最终如何驱动 Codex。executeReviewRuncodex-companion.mjs 约 L358的流程为ensureCodexAvailable(cwd)检查全局codex二进制存在且支持app-server高级运行时codex.mjs 的getCodexAvailability约 L886ensureGitRepository(cwd)git rev-parse --show-toplevel确认当前目录在 Git 仓库内resolveReviewTarget按上文规则解析目标validateNativeReviewRequest(target, focusText)拒绝任何 focus 文本、拒绝非原生目标runAppServerReview(cwd, { target, model, onProgress })真正发起审查。runAppServerReviewcodex.mjs 约 L1002是核心它通过withAppServer建立与 Codex app-server 的客户端连接然后thread/start以sandbox: read-only、ephemeral: true启动一个临时线程model 可选传入可被覆盖review/start向该线程发起内置评审请求delivery: inline默认target即前面解析出的uncommittedChanges或baseBranch目标captureTurn通过 app-server 通知流捕获整个 turn——enteredReviewModeReviewer started、exitedReviewMode捕获item.review作为reviewText、reasoning汇总推理摘要等事件都会被记录返回reviewText、reasoningSummary、threadId、turnId、status等交由上层渲染。关键设计点是只读双保险命令层禁止修改review-only 约束app-server 线程层也用sandbox: read-only兜底审查过程不可能写回工作区。同时withAppServer还实现了 broker 降级重连当共享会话broker繁忙BROKER_BUSY_RPC_CODE或不可达时自动回退到直接启动一个 app-server 实例保证审查不因共享运行时忙碌而失败。另外值得一提的是--model覆盖能力handleReviewCommand支持--model别名-m并经由normalizeRequestedModel把spark映射为gpt-5.3-codex-spark。不传时模型与推理力度完全由你的 Codex 配置决定见下节。如何配置审查使用的模型与推理力度/codex:review复用你本机 Codex CLI 的全部配置不引入独立运行时。想调整默认模型或 reasoning effort只需在项目根目录的.codex/config.toml或用户级~/.codex/config.toml中设置model gpt-5.4-mini model_reasoning_effort high配置加载顺序为用户级~/.codex/config.toml→ 项目级.codex/config.toml仅在项目受信任时加载。这样你在 Claude Code 里敲/codex:review时Codex 会使用与命令行直接使用完全一致的模型与推理策略审查质量与在 Codex TUI 中执行/review一致。实战建议与边界条件基于命令文档与源码实现总结几条可直接套用的实战经验多文件改动优先--background多文件审查耗时较长后台运行后配合/codex:status轮询、/codex:result取最终输出是最省心的组合提交前对比基准/codex:review --base main只审查你分支相对main引入的提交适合 PR 前的定向检查有未跟踪文件时别急新文件会被计入可审查工作ls-files --others会被收集审查前记得确认这些确实是你要评审的内容需要引导时切换命令想针对 auth、数据丢失、回滚、竞态等风险区域做定向挑战或想给审查加 focus 文本请改用/codex:adversarial-reviewread-only 保证命令层约束 sandbox: read-only双保险审查过程不会修改任何文件可以放心纳入常规提交流程。总结/codex:review把 Codex 的原生评审器以一条 slash 命令的形式接入 Claude Code参数层支持前台/后台/自动询问与--base/--scope目标控制执行层严格保持 review-only 与 stdout 逐字返回实现层则通过 app-server 的review/startRPC 以只读沙箱驱动 Codex 内置评审器。配合/codex:status、/codex:result、/codex:cancel你可以把提交前 Codex 审查编排成完整、可中断、可回溯的开发闭环——而这一切都复用于你本机已有的 Codex 安装、登录态与配置。赞分享人工智能AI 插件代码智能体【免费下载链接】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 的 /codex:status 命令完全指南在 Claude Code 中查看与跟踪 Codex 后台任务codex plugin cc 的 /codex:status 命令完全指南在 Claude Code 中查看与跟踪 Codex 后台任务 导读 /codex人工智能AI 插件代码智能体garak unsafe_content 检测器全解毒性模型与脏词表如何识别 LLM 不安全输出garak unsafe_content 检测器全解毒性模型与脏词表如何识别 LLM 不安全输出 导读 garak the LLM vulnerabilit人工智能AI 插件代码智能体CleanRL 完整上手指南5 分钟跑通单文件强化学习实验CleanRL 完整上手指南5 分钟跑通单文件强化学习实验 CleanRL 是一个深度强化学习库把 PPO、DQN、SAC 等主流算法以高质量单文件实现的方人工智能AI 插件代码智能体上一篇Erlang/OTP 30 移除计划详解Guard 类型测试别名、分布式协议与加密组件弃用清单下一篇Photoshop图层批量导出终极指南如何将工作效率提升90倍创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
