跳转至

原生 Codex 插件

原生 Codex 插件支持让 Codex 模式下的 OpenClaw 智能体能够在处理 OpenClaw 回合的同一 Codex 线程中使用 Codex app-server 自身的应用和插件能力。插件调用保留在原生 Codex 记录中;Codex app-server 负责应用支持的 MCP 执行。OpenClaw 不会将 Codex 插件转换为合成的 codex_plugin_* OpenClaw 动态工具。

在基础的 Codex harness 正常工作后,再使用本页。

要求

  • 智能体运行时必须是原生 Codex harness。
  • plugins.entries.codex.enabled 为 true。
  • plugins.entries.codex.config.codexPlugins.enabled 为 true。
  • Codex app-server 报告 0.149.0 或更高版本。官方插件随附 @openai/codex 0.158.0;较新的自定义、远程和 macOS 桌面应用自有二进制文件会继续运行,同时带有兼容性警告和正常运行时验证。
  • 目标 Codex app-server 能够看到预期的 marketplace、插件和应用清单。
  • 迁移仅支持其在源 Codex home 中观察到以源安装方式安装的 openai-curated 插件。Codex 以 openai-api-curated 线上名称向 API 密钥和 Bedrock 账户提供相同的目录;OpenClaw 将这两个名称视为同一个 curated 目录,因此配置的 openai-curated 插件可以从任一名称解析。
  • 原生运行时支持还包括 Codex 已经可用的其他 marketplace,例如 openai-bundled、openai-primary-runtime、workspace-directory,以及当前仓库中的 marketplace 清单。在所有者或 operator.admin 明确安装或启用其 marketplace 限定身份之前,插件保持不可用。

codexPlugins 对 OpenClaw-provider 运行、ACP 会话绑定或其他 harness 没有影响,因为这些路径永远不会创建带有原生 apps 配置的 Codex app-server 线程。

OpenAI 侧的 Codex 账户、应用可用性以及工作区应用/插件控制来自已登录的 Codex 账户。有关 OpenAI 账户和管理员模型,请参阅将 Codex 与您的 ChatGPT 套餐配合使用。

快速开始

源 Codex home 是您要迁移的 Codex CLI 状态目录:默认是 ~/.codex,当设置了该变量时则是 CODEX_HOME。参见 openclaw migrate 了解如何使用 --from 指向其他目录。

预览从源 Codex home 进行的迁移:

openclaw migrate codex --dry-run

添加 --verify-plugin-apps 让迁移读取源安装的应用快照和应用元数据,要求在规划原生激活之前,每个拥有的应用都必须存在、启用且可访问:

openclaw migrate codex --dry-run --verify-plugin-apps

当计划看起来正确时,应用迁移:

openclaw migrate apply codex --yes

迁移会为符合条件的插件写入显式的 codexPlugins 条目,并为选定的插件调用 Codex app-server 的 plugin/install。迁移后的配置如下所示:

{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          codexPlugins: {
            enabled: true,
            allow_destructive_actions: true,
            plugins: {
              "google-calendar": {
                enabled: true,
                marketplaceName: "openai-curated",
                pluginName: "google-calendar",
              },
            },
          },
        },
      },
    },
  },
}

迁移仍仅限于 openai-curated。要查找 Codex 已经可以看到的其他插件,请列出可用的 marketplace 目录,并安装精确的 marketplace 限定身份:

/codex plugins available
/codex plugins install security-review@company-tools
/codex plugins status security-review@company-tools

Codex 从当前会话工作区中的 .agents/plugins/marketplace.json 发现仓库 marketplace。所有者无需在列出或安装其插件之前将该 marketplace 添加到 OpenClaw 配置中。官方的 bundled、primary-runtime、curated、workspace、共享和个人 marketplace 取决于已登录的 Codex 账户以及上游功能或管理员策略。当 Codex 要求显式配置 marketplace 来源或将其加入允许列表时,这些要求仍然适用;OpenClaw 不会绕过它们。

安装会写入一个显式的配置条目,例如:

{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          codexPlugins: {
            enabled: true,
            plugins: {
              "security-review@company-tools": {
                enabled: true,
                marketplaceName: "company-tools",
                pluginName: "security-review",
              },
            },
          },
        },
      },
    },
  },
}

安装命令在调用 Codex 的 plugin/install 之前,会先检查已认证的所有者或管理员。Codex 会继续强制执行 marketplace 来源、工作区管理员、账户和连接器认证策略。需要 Codex 安装过渡页、或未报告是否需要过渡页的远程插件,必须先安装到 Codex 中;之后重新运行 OpenClaw 安装命令以授权已安装的插件。当响应缺少确切的 marketplace、插件身份、详情身份或应用就绪证据时,OpenClaw 会保持应用隐藏。如果连接器需要额外的登录,请先完成该授权,再期望插件的工具变为可用。

安装插件包和配置 OpenClaw 应用访问并不确认托管应用连接。当安装返回仍需要登录的应用时,OpenClaw 会提供 Open <app> in ChatGPT 链接,指向 Codex 返回的应用页面。请使用 Codex harness 所使用的同一个 ChatGPT 账户和工作区登录。打开链接不会验证连接,也不会使其工具在当前会话中可调用。如果浏览器显示的是目录而不是应用,或者没有可用的安全链接,请在 Codex CLI 中运行 /apps 并在此处选择应用。响应最多显示五个应用链接,并明确报告需要在 Codex CLI 中查看的其他应用。这些链接适用于托管的 ChatGPT 应用;原生 MCP 服务器设置仍然独立。

应用也可以在你首次使用其某一工具时请求登录。在 Control UI 中,选择 打开链接 以在单独的标签页中打开请求的页面。在你登录期间,该问题保持待处理状态。完成浏览器步骤后,选择 我已完成此步骤 并提交,让 Codex 刷新并重试。仅打开链接并不会恢复工具或确认连接。没有链接操作的客户端仍会在回答前显示需要手动打开的 URL。

对于在活动 Codex 登录提示之外完成的设置,请刷新当前 Codex 账户/运行时中托管的应用清单:

/codex plugins refresh

此刷新会覆盖该运行时中的所有托管应用;它不是针对单个插件的后端刷新。插件的 刷新托管应用 按钮会运行此命令。单独的 检查状态 按钮仅检查该插件,不会刷新托管工具。这两种操作都不会更改授权或当前对话的应用策略。连接后使用 /new 或 /reset,然后在新对话中检查状态。

codexPlugins 更改后,新的 Codex 对话会自动采用更新后的应用集合。运行 /new 或 /reset 可刷新当前对话。启用/禁用插件的更改不需要网关重启。

计划自动化

当经过身份验证的所有者从 Codex 回合创建自动化时,OpenClaw 会捕获可在该确切 Codex 线程上调用的应用 ID 和审批限制。存储的授权绑定到创建者准备好的 Codex 配置文件和账户。计划运行将该上限与当前的 Codex 策略及应用可用性相交集。它们永远不会获得新的应用 ID,也不会获得更宽泛的破坏性、开放世界或审批上限。在所捕获应用内后续添加的工具,只有在存储的上限和当前策略都允许时才能运行。

计划中的应用调用是无人值守的。只有在创建作业时和运行时都被明确允许的操作,才可以在没有提示的情况下继续执行。仍需要审批或引导的操作会被拒绝。账户变更、运行时变更、应用被撤销、策略变窄或清单不可用,都会在应用执行前停止,并报告如何恢复访问或重新授权自动化。模型回退不能将此授权移动到另一个运行时或账户。

这条路径比普通的交互式回合更严格。OpenClaw 会根据当前工具元数据和捕获的授权,生成每个工具的 enabled 和 approval_mode 值。显式的原生 enabled: true 不能覆盖计划运行中已捕获或当前的破坏性/开放世界限制。审批交集会在任一方要求时保留 "prompt";"approve" 则遵从另一方。将 "auto" 与 "writes" 组合会生成 "prompt",因为它们依赖注解的规则并非完全有序。

在捕获应用授权之前创建的作业可以保留其普通的 OpenClaw 工具上限,并继续非应用工作,但无法自动恢复 Codex 应用访问。只有需要应用访问的作业,才应从一个新的、经过身份验证的所有者回合重新创建或重新授权。参见 自动化。普通编辑会保留捕获的应用授权。如果没有新的、经过身份验证的 Codex 授权捕获,显式替换作业的 toolsAllow 上限会清除该授权;下一次运行会报告应用访问需要重新授权。来自新的、经过身份验证的所有者回合的更新,则可以为更新后的作业捕获并存储新的应用上限。

从聊天中管理插件

/codex plugins 检查或更改已配置的原生 Codex 插件,操作方式与你操作 Codex harness 的聊天相同:

/codex plugins
/codex plugins list
/codex plugins available
/codex plugins available security
/codex plugins available --page 2
/codex plugins install security-review@company-tools
/codex plugins status security-review@company-tools
/codex plugins refresh
/codex plugins disable google-calendar
/codex plugins enable google-calendar
/codex plugins disable security-review@company-tools

/codex plugins 是 /codex plugins list 的别名。该列表显示每个已配置插件的键、开/关状态、Codex 插件名称以及来自 plugins.entries.codex.config.codexPlugins.plugins 的市场。

available [query] [--page <n>] 需要所有者或 operator.admin 权限。它使用绑定的工作区读取 Codex 的市场目录,包括仓库本地插件,而不会安装或启用它们。搜索会在返回的整个目录中不区分大小写地匹配名称、显示标题、发布者、市场和描述,然后每页显示十条结果。下一页 和 上一页 会保留你的搜索;没有按钮的频道会显示要发送的命令。搜索文本限制为 100 个字符。对于包含 --page 的字面搜索文本,请在前面使用 --。

结果会显示 Codex 提供的显示标题、发布者和描述;对于缺失的发布者或描述,会显示显式占位符。它们保留市场限定的身份和可用性限制;显示标题和发布者名称不会改变安装身份。此搜索针对 Codex 目录,而非 OpenClaw 的插件注册表或每个 ChatGPT 连接。所有者范围的 codex_plugins 模型工具使用相同的搜索匹配,并且同样只读:它可以推荐确切的安装命令,但不能安装、启用或添加市场。

status <name>@<marketplace> [page] 仅检查一个已配置的插件,并且需要所有者或 operator.admin 权限。必须使用限定身份;单独的 status 或未限定的名称会返回指向 list 的用法说明。

状态命令会分别显示捆绑包安装情况、市场限制、Codex 启用状态以及共享的 OpenClaw 应用访问权限。对 OpenClaw 应用访问权限的更改会在下一条消息时生效;它们不会安装或启用 Codex 捆绑包。

应用结果每页最多显示五个应用。ChatGPT 应用页面链接需要已确认的托管应用运行时支持、其目录策略下可用的插件,以及与 app/read 匹配的授权元数据。仅凭插件的应用声明或设置 URL 并不能确立该访问权限。即使符合条件的 ChatGPT 页面仍然可用,OpenClaw 应用访问权限也可能已被禁用;打开该页面并不会启用 OpenClaw 应用访问权限。没有托管应用的插件不会收到 ChatGPT 连接或设置指导。状态命令不会评估它们的技能或原生 MCP 服务器就绪状态。

当可用时,会显示所选代理、身份验证配置、会话工作区以及账户邮箱/套餐。当 Codex 未报告时,ChatGPT 工作区身份仍未知;在打开符合条件的托管应用页面时,请在浏览器中使用相同的账户和工作区。

状态使用 app/read 获取应用元数据,并显示 app/installed 返回的 enabled 和 callable 标志。运行时作用域在可用时为绑定的 Codex 线程,否则为账户。这些标志反映有效的 Codex 配置和当前运行时工具快照;它们与 OpenClaw 应用访问权限相互独立。状态不会推断出独立的连接状态。缺失的应用记录和读取失败会被明确报告,而不是变成虚假标志。

/codex plugins refresh 需要所有者或 operator.admin 权限,并且所选 Codex 账户/运行时已确认支持托管应用。即使未配置插件,它也能工作。它会使该运行时的 OpenClaw 应用缓存失效,调用 Codex app/installed,参数为 forceRefresh: true 且不带 threadId,并读取返回应用的元数据。它不会刷新市场目录、重新安装插件包或重新加载原生 MCP 服务器。

刷新后,使用 /codex plugins status <name>@<marketplace> 检查单个插件。状态永远不会强制托管刷新。已禁用或被阻止的插件仍保持禁用或阻止状态,但不会阻止其他情况下允许的托管刷新。

请求完成并不能证明 Codex 已替换其快照,也不能证明实时工具调用会成功。刷新永远不会安装、启用、认证或替换线程,也不会重新加载其他会话。连接后,使用 /new 或 /reset 并再次检查状态。浏览器设置不会改变 OpenClaw 应用访问权限;本地应用访问权限更改将在下一条消息时生效。不支持的方法、取消和刷新失败会提供重试操作,而不会将之前的清单视为已确认。

install、enable 和 disable 需要所有者或具有 operator.admin 作用域的网关客户端。OpenClaw 的保留 /codex 命令在调用代理之前分发,因此模型生成的建议不算作安装批准。对于 Codex 尚未安装的插件,install 会调用 Codex app-server,并且仅在安装成功后记录显式插件策略。如果 Codex 确认该插件已安装并启用,同一命令会记录其授权而不会再次安装。enable 和 disable 会更改 OpenClaw 的持久化策略;限定身份和现有配置键均被接受。

安装或启用已配置的插件还会打开全局 codexPlugins.enabled 开关,而不会启用 allow_all_plugins。如果插件报告 auth_required,请在开始新会话前在 Codex 中授权该应用。授权对后续会话保持有效,直到插件被禁用或上游账户或工作区撤销访问权限。

只安装你信任的插件。Codex 插件可以提供技能、应用、MCP 服务器和钩子。某些钩子可以参与权限决策,因此显式安装即信任所选插件的代码;它不是安全审查或隔离边界。

原生插件设置如何工作

该集成跟踪三种状态:

状态 含义
已安装 Codex 在目标 app-server 运行时中拥有该插件包。
已启用 Codex 报告该插件已启用,并且 OpenClaw 配置允许其在 Codex 运行框架轮次中使用。
可访问 Codex app-server 确认该插件的应用条目对当前账户可用,并映射到已配置的插件身份。

对于 openai-curated 插件,迁移是持久的安装/资格步骤:

  • 在规划期间,OpenClaw 读取源 Codex plugin/read 详情并检查源 Codex app-server 账户。codex_subscription_required 表示 account/read 已明确识别出 API 密钥或其他非 ChatGPT 账户;缺失账户并不能证明不存在订阅。
  • 默认情况下,迁移会跳过源应用清单调用:通过账户门槛的应用支持型源插件会在不进行源应用可访问性验证的情况下进行规划。缺失账户或 account/read 失败会以 codex_account_unavailable 跳过它们。
  • 使用 --verify-plugin-apps 时,迁移会获取新的源 app/installed 快照,使用 app/read 获取经过身份验证的元数据,并要求在规划原生激活之前,每个拥有的应用在源 Codex 账户中都存在、已启用且可访问。如果 account/read 缺失或失败,严格验证仍可通过源 app-server 配置的 bearer 或 header 身份验证来证明访问权限。被明确识别的非 ChatGPT 账户仍不符合条件。

对于来自任何已发现市场的显式批准插件,OpenClaw 使用其 plugin/installed 快照和 plugin/read 详情来确定精确的市场限定身份和应用所有权。普通线程设置期间的仅已安装检查是只读的;来自已禁用或未批准插件的应用仍被拒绝。所有者发起的安装是显式变更路径。缺失或所有权不明确时会失败关闭,而不是授予账户范围的访问权限。

运行时应用清单是针对已迁移的精选插件和手动配置的工作区插件的目标会话可访问性检查。在启用策略轮次之前(包括热复用和冷恢复),Codex 运行框架会根据当前原生设置重建限制性线程应用策略,同时复用其应用清单和插件元数据缓存。

支持边界

  • 仅源 Codex app-server 清单中已安装的 openai-curated 插件符合迁移条件。
  • 运行时支持来自 Codex 发现的官方、工作区、个人、共享和仓库本地市场中明确批准的插件。缺少市场、插件、所有权详情或应用就绪证据时,不会暴露任何插件应用。
  • 被明确识别为非 ChatGPT 的源账户会未通过订阅检查。缺失或不可读的源账户默认不可用。 --verify-plugin-apps 可以改为通过已认证的源应用清单建立访问,包括使用 bearer 或 header 认证的 app-server。 无法访问、已禁用或缺失的源应用以及清单刷新失败仍保持为跳过的手动项。不可读的插件详情会在应用清单检查之前被跳过。
  • 迁移会写入显式插件标识(marketplaceName 和 pluginName);它不会写入本地 marketplacePath 缓存路径。
  • codexPlugins.enabled 是唯一的全局启用开关;不存在 plugins["*"] 通配符或可授予任意安装权限的配置键。
  • 迁移不会自动导入非精选市场、缓存的插件包、hooks 或 Codex 配置文件。使用 /codex plugins available 以及由所有者发出的 /codex plugins install <plugin>@<marketplace> 命令,可选择加入额外发现的插件。
  • OpenClaw 不会在此流程中添加新的 Git 或本地市场源。 额外源必须已在 Codex 中配置,或可从绑定的仓库中发现。

应用清单与所有权

OpenClaw 首先读取并缓存一个 plugin/installed 快照,其范围限定为目标 Codex app-server 和已配置的工作区。该快照覆盖该范围内可见市场中的插件,包括已禁用的插件标识;失败或不完整的快照永远不会被缓存。同一运行时和工作区中的会话共享此元数据,并且所有者安装会使它们全部失效。应用就绪状态仍特定于每个线程。 plugin/read 仅限于建立所有权所需的精确已配置插件详情。 显式发现查询使用会话工作区调用 plugin/list 以查找仓库市场。常规设置保留其现有的精选恢复行为;额外市场安装需要明确的所有者或管理员命令。

Codex 在插件安装后负责 skill、hook 和 MCP 的刷新。OpenClaw 刷新其插件和应用清单,而不会重新加载无关线程。 如果较旧的自定义 Codex 运行时未使新安装的插件在现有会话中可用,请使用 /new 或 /reset。

OpenClaw 通过 app/installed 读取已安装应用运行时状态,并使用 app/read 以最多 100 个应用 ID 的批次获取规范应用元数据。首次读取会强制刷新冷安装运行时快照。当安装了多个已配置的精选插件时,OpenClaw 会将它们各自的缓存失效合并为一次应用清单刷新。普通缓存读取不会为每个新线程强制连接器刷新。OpenClaw 在内存中缓存合并后的清单一小时,并异步刷新过期或缺失的条目。缓存是进程本地的;重启 CLI 或网关会丢弃它。

缺少清单方法、认证错误、传输失败和连接器刷新失败不会允许应用工具。普通回合,包括使用 allow_destructive_actions: "ask" 的回合,在清单超过其启动预算时,可以在禁用原生应用的情况下继续。如果其捕获的应用策略无法在该预算内重新验证,计划运行将停止。

迁移和运行时使用不同的缓存键:

  • 源迁移验证使用源 Codex 主目录和启动选项。它仅在 --verify-plugin-apps 下运行,并强制为那次规划运行获取新的源运行时快照和元数据读取。
  • 目标运行时设置使用目标代理的 Codex app-server 标识来构建和验证线程应用配置。精选插件激活会使该目标缓存键失效,然后在 plugin/install 后强制刷新它。显式市场安装会在后续会话使用该插件之前刷新同一目标运行时状态。

只有当 OpenClaw 能够通过稳定所有权将其映射回已配置插件时,才会暴露插件应用:来自插件详情的精确应用 ID、已知的 MCP 服务器名称,或唯一稳定的元数据。仅显示名称或所有权不明确的情况会被排除,直到下一次清单刷新证明所有权。

缺失的插件和市场会保留在已保存设置中以便未来发现,但会被排除在有效运行时插件策略之外。OpenClaw 会记录错误并继续使用健康的插件和已连接账户应用。缺失条目的权限不适用于其他应用,即使它们的显示名称匹配。该条目会在下一次正常清单刷新时重新考虑;不会删除已保存设置。由管理员禁用的已发现插件保留其限制。

已连接账户应用

所有者操作的代理可以选择加入其 Codex 账户已连接的每个应用,而不需要匹配的插件包:

{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          codexPlugins: {
            enabled: true,
            allow_all_plugins: true,
            allow_destructive_actions: "auto",
          },
        },
      },
    },
  },
}

allow_all_plugins: true 在新原生 Codex 线程建立时读取已安装应用快照和已认证元数据。它仅允许账户可访问的应用。Codex 还必须确认每个被允许的应用对该线程已启用且可调用。OpenClaw 不会全局安装、认证或启用应用。现有线程保留其持久化的应用集;使用 /new、/reset 或重启网关以获取新连接或已撤销的应用。

一个在清单中明确禁用的已配置插件会覆盖整个账户的应用访问。由于 Codex app/read 会省略已禁用工作区插件的显示名称,OpenClaw 会使用其 plugin/installed 快照,并只读取该确切已配置插件的详细信息,以保留其拥有的应用 ID。这一范围狭窄的只读检查不会发现无关的市场,不会激活该插件,也不会授予其应用。如果无法确定该已禁用插件的所有权,整个账户的应用选择会以失败关闭方式处理。

账户应用继承全局 codexPlugins.allow_destructive_actions 值,该值接受 true、false、"auto" 或 "ask"。显式的按插件策略会覆盖重叠应用 ID 的全局策略。清单失败会以失败关闭方式处理,而不是回退到不受限制的默认值。

线程应用配置

OpenClaw 会为 Codex 线程注入一个限制性 config.apps 补丁:_default 被禁用,只有由已启用的已配置插件拥有的应用,或由 allow_all_plugins 允许访问的账户应用才会被启用。

在 _default 被禁用时,一个应用可以在整个账户快照中已安装并已认证,但不可调用。OpenClaw 会临时只允许所有权已证明且策略允许的应用,创建限制性线程,然后使用生成的线程 ID 和 forceRefresh: false 重新读取一次 app/installed。如果快照报告某个应用缺失、已禁用或不可调用,OpenClaw 会记录一条警告,列出不可用的应用,并继续使用剩余工具。Codex 仍会执行线程的有效应用、托管、工作区和工具策略。不可用的可选应用不会阻止无关的聊天或心跳运行。

如果快照请求本身失败,临时线程永远不会绑定或使用。OpenClaw 会删除失败的持久临时线程,取消订阅失败的短暂线程,并在无法确认安全清理时退役 app-server 连接。

每个应用上的 destructive_enabled 来自有效全局或按插件 allow_destructive_actions 策略;true、"auto" 和 "ask" 都会设置 destructive_enabled: true,而 false 会将其设置为 false。Codex 仍会按照以下顺序评估原生工具启用状态和注释。_default 以 open_world_enabled: false 禁用;已启用的插件应用获得 open_world_enabled: true。OpenClaw 不暴露单独的插件级开放世界策略旋钮,也不维护按插件的破坏性工具名称拒绝列表。

审批决策顺序

对于普通交互式 Codex 轮次,按以下顺序遵循这些决策:

  1. 准入: OpenClaw 选择此线程上允许的插件/应用身份。不可用的清单或未证明的所有权不会授予访问权限。
  2. 线程配置: OpenClaw 将其应用策略叠加到目标 app-server 的原生配置上。Codex 管理要求仍然适用。
  3. 工具启用: Codex 决定特定工具是否可调用。已禁用的工具不能通过批准提示变为可调用。
  4. 审批模式和审阅者: Codex 决定调用是否需要审查,以及是使用其自动审阅者还是发送用户审批请求。
  5. OpenClaw 响应: 当插件审批请求到达 OpenClaw 时,其征询桥接会应用有效的 allow_destructive_actions 值。

这些是独立的决策。enabled: true 不意味着自动批准,approval_mode: "approve" 也不会启用已禁用的工具。OpenClaw 动态工具、普通 MCP 表单和原生 shell 权限有各自的流程;参见 原生权限和 MCP 征询。

哪个配置负责每个设置

设置 负责方和用途
plugins.entries.codex.config.codexPlugins OpenClaw 的准入和插件征询策略。
codexPlugins.allow_destructive_actions 已配置插件和被允许账户应用的共享 OpenClaw 默认值。
codexPlugins.plugins.<key>.allow_destructive_actions 针对该已配置插件的显式覆盖。
原生 apps._default、apps.<appId> 和 apps.<appId>.tools 在配置层和 OpenClaw 线程补丁合并后,Codex 应用默认值和按工具设置。
plugins.entries.codex.config.appServer.approvalPolicy 和 approvalsReviewer 通用 Codex 审批姿态和审阅者,区别于应用/工具策略。参见 审批和沙箱模式。

OpenClaw 按以下方式解析破坏性操作设置:

per-plugin value ?? codexPlugins shared value ?? true

省略按插件值会继承共享值。显式 false、true、"auto" 和 "ask" 都会覆盖它。特别是,生成的按插件 "auto" 会覆盖共享 false;"auto" 是策略值,而不是继承指令。

共享默认值与插件条目位于同一个 OpenClaw 配置中。它不需要单独的主机范围配置文件。原生 Codex 设置属于运行工具的 app-server:默认托管本地服务器使用 agent 范围的 Codex home;远程服务器使用其自己的配置。从 OpenClaw 或部署管理器启动 Codex 不会移除这个原生配置层。OpenClaw 的线程补丁不会重写已保存的原生设置。

原生工具启用

在 OpenClaw 的准入补丁之后,Codex 按以下顺序评估应用工具:

  1. 已禁用的应用会阻止其所有工具,包括显式启用的工具。 受管应用的禁用仍具有最终决定权。
  2. 显式 apps.<appId>.tools.<tool>.enabled 对该工具优先。
  3. 否则,显式 apps.<appId>.default_tools_enabled 优先。
  4. 否则,Codex 根据工具的注解检查 destructive_enabled 和 open_world_enabled。 每个类别设置从应用回退到 apps._default,再回退到 true。缺失的注解在此资格检查中按破坏性/开放世界处理。

对于工具配置,精确工具名称条目优先于工具标题条目。 Codex 首先选择整个条目;它不会从标题条目中补全缺失字段。 省略 enabled 以继承;TOML 没有 null 值。

例如,在具有 destructive_enabled: false 的已准入应用上,省略工具 enabled 会使破坏性工具保持被阻止。 显式 enabled: true 允许该特定工具通过此原生资格检查,而 enabled: false 即使应用允许破坏性工具也会阻止它。 该调用仍必须通过审批和执行检查。 这是对应用默认设置的例外,而不是启用未准入应用或扩大计划权限的方式。

原生审批模式

对于已启用的工具,Codex 会选择第一个适用的审批模式:

  1. 受管的逐工具审批要求。
  2. 所选原生工具条目的 approval_mode。
  3. 所选已连接账户的 apps.<appId>.links.<linkId>.default_tools_approval_mode。
  4. apps.<appId>.default_tools_approval_mode。
  5. apps._default.default_tools_approval_mode。
  6. "auto"。

账户链接是本次调用使用的已连接账户,而不是 OpenClaw 会话。 以下模式决定是否需要审查;它们本身并不承诺 OpenClaw 提示:

原生模式 审批要求
"approve" 无工具审批请求。其他访问和执行限制仍然适用。
"prompt" 需要审批,包括只读工具。
"writes" 需要审批,除非工具明确声明自己为只读。
"auto" 使用注解:明确破坏性的工具需要审批;否则明确只读的工具不需要。其余工具在破坏性/开放世界提示为 true 或缺失时需要审批。

审查者选择是独立的:已连接账户的审查者优先于应用审查者,然后是 apps._default.approvals_reviewer,再然后是线程审查者。 Codex 仅接受管理要求允许的已配置审查者;否则使用线程审查者。 针对自动审查的模型特定要求优先。 严格自动审查也可以在工具模式本会跳过审查时要求审查。

除非 OpenClaw 策略显式为 "ask",已准入应用保留其原生审批模式和审查者,包括应用默认设置以及已保存的账户链接或工具覆盖。 恢复线程或提出 /btw 旁路问题时也是如此。 如果没有原生审批设置,Codex 回退到 "auto"。

使用 OpenClaw allow_destructive_actions: "auto" 将原生人工审批请求通过 OpenClaw 同意流程路由。 使用 "auto_review" 审查者的原生 "prompt" 仍保留在 Codex 的自动审查流程中。 OpenClaw true 也保留原生模式,但会自动接受到达桥接的受支持审批请求,如下所述。

OpenClaw "ask" 还会为当前非只读工具名称/别名和已连接账户覆盖已保存的审批字段,选择原生 "auto" 以及人工应用/账户审查者。 它保留工具启用状态。 如果工具摘要不可用,它会针对所有已保存的工具审批条目。 因此,"ask" 要求对 Codex 发送审批的操作进行一次性同意;它并不意味着对每次读取都使用原生 "prompt"。 其他应用保留其审查者。

在普通原生插件轮次和带有绑定应用的 /btw 旁路问题中,即使通用 appServer.approvalPolicy 为 "never",OpenClaw 也会启用 MCP 征询委托;这不会启用无关的 shell 审批类别。 应用模式、审查者和桥接响应仍决定结果。 通用审批策略不能替代上述逐应用/工具设置。

破坏性操作策略

对于已配置的 Codex 插件,破坏性插件征询默认允许,而不安全架构和所有权不明确会失败关闭:

  • 全局 allow_destructive_actions 默认为 true。
  • 逐插件 allow_destructive_actions 覆盖该插件的全局策略。
  • false:OpenClaw 设置原生 destructive_enabled: false;工具资格遵循上述原生默认设置和显式例外。 符合条件的托管应用工具的审批请求仍会通过 OpenClaw 同意,包括允许的读取和 /btw 旁路问题。 桥接不会再次对工具进行分类,也不会一概拒绝其请求。 插件提供的 MCP 服务器审批请求仍会收到确定性拒绝。
  • true:OpenClaw 仅自动接受它可以映射到审批响应的安全架构,例如布尔审批字段。
  • "auto":OpenClaw 向 Codex 公开破坏性插件操作,然后在返回 Codex 审批响应之前,将所有权已证明的 MCP 审批征询转换为 OpenClaw 插件审批。
  • "ask":OpenClaw 使用与 "auto" 相同的 Codex 写入/破坏性门控,应用上述工具/账户审批覆盖,并且只提供一次性审批或拒绝。 已保存的原生设置保持不变,用户配置重载会保留线程的审批策略。 这些检查也会在重用线程或回答 /btw 旁路问题之前运行。 更改的覆盖键会使用当前策略重建线程。
  • 缺少插件身份、所有权不明确、缺少或不匹配的轮次 id,或不安全的征询架构会拒绝而不是提示。

不在已准入策略范围内的应用将保持禁用状态,即使原生 Codex 设置启用了它们。在已启用的策略能够准入应用工具之前,必须验证原生设置。当没有任何应用可以被准入时,Codex 的应用工具界面会被禁用,而不会读取原生应用设置。禁用插件应用也会跳过应用清单发现。处于活动状态的旧版托管应用设置优先于原生线程配置,并阻止应用准入;请将这些应用设置迁移到受支持的用户或项目配置层。原生管理要求仍然具有权威性。

审批示例

假设存在一个已准入且已认证的应用、没有冲突的托管要求,并且对于需要审批的调用存在一名人工审核者。以下读取工具声明了 readOnlyHint: true 和 destructiveHint: false:

配置 普通回合中的可观察结果
OpenClaw 共享 false,按插件 "auto" 插件覆盖生效。破坏性工具符合资格;到达 OpenClaw 的审批提示会请求同意。
OpenClaw "auto",原生应用默认 "prompt",无工具/链接覆盖,非破坏性读取 原生 "prompt" 保留。读取请求同意;“允许一次”允许该调用,“拒绝”阻止它。
OpenClaw "auto",原生读取工具 approval_mode: "prompt" 按工具模式保留。读取请求同意;“允许一次”允许该调用,“拒绝”阻止它。
OpenClaw false,原生应用默认 "prompt",无工具/链接覆盖,非破坏性读取 原生资格允许读取,并且 OpenClaw 请求同意。“允许一次”允许该调用,“拒绝”阻止它。
OpenClaw false,破坏性工具显式 enabled: true 且 approval_mode: "approve" 原生工具例外会绕过类别默认值,并且不需要工具审批请求。桥接的拒绝路径不是执行时的类别上限。
OpenClaw "ask",已保存的非只读工具审批 "approve" 线程覆盖层会用原生 "auto" 替换该已保存审批;需要审批的调用使用一次性同意。

如果原生 "prompt" 示例中的审核者是 "auto_review" 而不是 "user",Codex 会执行自动审核,而不是显示 OpenClaw 同意提示。两种审核者选择都不会启用未通过资格检查的工具。

已记住的审批和显式启用是不同的设置。Codex 的持久化应用工具审批会写入 approval_mode: "approve",而不是 enabled: true;“允许一次”不会持久化任一设置。在解释某个工具为何运行或为何没有提示时,请重新检查这两项。

故障排除

代码 含义 修复方法
auth_required 迁移已安装插件,但其其中一个应用仍需要认证。在重新授权之前,该条目会被写入为禁用状态。 在 Codex 中重新授权该应用,然后在 OpenClaw 中启用插件。
app_inaccessible, app_disabled, app_missing 使用 --verify-plugin-apps 时,源 Codex 应用清单未显示所有自有应用均存在、已启用且可访问。 在 Codex 中重新授权或启用该应用,然后使用 --verify-plugin-apps 重新运行迁移。
app_inventory_unavailable 请求了严格的源应用验证,但源 Codex 应用清单刷新失败。 修复源 Codex app-server 访问,或者不使用 --verify-plugin-apps 重试,以接受更快的基于账户门控的计划。
codex_subscription_required 源 app-server 明确识别出 API 密钥或其他非 ChatGPT 账户。 使用订阅认证登录 Codex 应用,然后重新运行迁移。
codex_account_unavailable 源账户缺失,或者在未进行严格应用验证的情况下 account/read 失败。 恢复源账户访问权限,或者在已认证的源应用清单能够证明访问权限时使用 --verify-plugin-apps。
marketplace_missing, plugin_missing 确切的市场或已配置插件在安装快照中不可用;插件应用会失败关闭。 验证目标 app-server 的 plugin/installed 响应以及确切的已配置插件标识。
plugin_detail_unavailable OpenClaw 无法读取确切已配置插件的所有权详情。 检查目标 app-server 的 plugin/installed 和 plugin/read 响应。
代码 含义 修复
plugin_disabled Codex 报告该插件已安装但处于禁用状态。 在 Codex 中启用该插件,或让所有者重新显式安装并授权它。
plugin_activation_failed 插件激活未完成。 使用附带的诊断信息来区分市场、认证、刷新或工作区就绪失败。
app_inventory_missing, app_inventory_stale 应用就绪状态来自空缓存或过期缓存。 OpenClaw 会自动安排异步刷新;在所有权和就绪状态已知之前,插件应用保持排除状态。
app_ownership_ambiguous 应用清单仅通过显示名称匹配。 在后续刷新证明所有权之前,该应用对 Codex 线程保持隐藏。

工作区插件已安装但不可见: 确认工作区 plugin/installed 快照报告确切的已配置 ID 为已安装且 已启用,然后确认 app/installed 返回同一 Codex 账户拥有的每个应用,并且 app/read 返回其元数据。仅由 账户范围默认设置禁用的应用,在 OpenClaw 启动并验证 其显式配置的线程后,可能变为可调用。已撤销的认证、缺失的元数据、禁用的 工作区插件,以及 Codex 托管或工作区限制仍会阻止 访问。在启动新线程之前,重新授权或修复这些上游条件。如果你在网关缓存应用清单后更改了该状态,请运行 /codex plugins refresh,然后使用 /new 或 /reset。 OpenClaw 不会代表所有者对插件应用进行认证。

对于 plugin_detail_unavailable,请验证确切的已安装市场 和插件身份能够选出匹配的 plugin/read 结果。当该选择器或所有权详情不可用时,OpenClaw 会保持 拥有的应用隐藏。对于 plugin_activation_failed,请检查市场、应用授权以及 安装后刷新诊断。显式批准的插件必须 已安装、已启用且已认证,其应用才能出现在线程中。

配置已更改但代理无法看到插件: 运行 /codex plugins list 以确认已配置状态,然后运行 /new 或 /reset。现有 Codex 线程绑定会保留其启动时的应用配置,直到 OpenClaw 建立新的框架会话或替换过期绑定。

破坏性操作被拒绝: 检查全局和按插件的 allow_destructive_actions 值。即使为 true、"auto" 或 "ask", 不安全的提示架构和模糊的插件身份仍会失败关闭。

本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 cl/openclaw