Workflow MCP

Workflow MCP standalone

Workflow MCP 可将兼容 Claude 的 JavaScript 工作流定义作为持久化的、由 Codex 支持的 MCP 任务运行，无需 Agent Code。Docker 负责运行时、Codex CLI、凭据、状态和进程隔离；正常运行无需在主机上安装 Node.js、Codex 或 Agent Code。主机运行时需要本地 Docker Engine 或 Docker Desktop，以及 Compose。经过验证的版本引导流程还需要 GitHub CLI（gh）、tar、sha256sum 或 shasum，以及 POSIX shell；Windows 则使用 PowerShell 7 和相应的内置归档／哈希命令。

Codex 的 Linux Bubblewrap 边界要求 Docker 主机启用非特权用户命名空间。Docker Desktop 提供此 Linux 虚拟机功能。原生 Linux 操作人员必须允许容器运行时创建嵌套用户命名空间；Ubuntu 24.04 启用了 AppArmor 限制，除非管理员提供适当的 AppArmor 策略，或修改文档中所述的 kernel.apparmor_restrict_unprivileged_userns 主机设置，否则可能会阻止这些操作。公开 kernel.unprivileged_userns_clone 的主机也必须启用该设置。Docker 的默认 seccomp 和 AppArmor 配置文件会分别阻止 Bubblewrap 所需的命名空间系统调用和挂载传播，因此，已发布的 Compose 和 OCI Registry 配置文件会为每个容器应用 seccomp=unconfined 和 apparmor=unconfined 例外。这些例外会启用内部 Codex 沙箱；不会将其禁用。容器仍以非 root 身份运行，移除所有能力，启用 no-new-privileges，使用只读挂载，并限制资源。如果真实沙箱探测无法启动，启动器和 doctor 会拒绝继续运行。不要将此运行时配置替换为特权容器、添加的能力、可写的外部挂载或已禁用的 Codex 沙箱。请参阅 Docker 运行时安全选项 和 Ubuntu 24.04 安全说明。

常规安装方式是每个项目运行一个长期驻留的守护进程。Codex 通过 docker compose exec 连接到一个精简的 STDIO 代理，因此断开一个 MCP 客户端不会取消守护进程或其运行任务。另有一种与会话绑定的 STDIO 镜像模式，适用于通用 OCI/MCP Registry，但其生命周期约定范围更窄。

安装

在项目目录中，匹配的发行版发布后，运行一条命令：

curl -fsSL https://github.com/Juliusolsson05/workflow-mcp/releases/latest/download/install.sh | sh

此脚本只需要 Docker。它会拉取由不可变摘要固定的发行版镜像（摘要会写入每份已发布的 install.sh 副本中，因此便捷 URL 无法决定实际运行的内容），从该镜像生成经过校验和验证的安装包，安装项目范围的启动器，写入 Codex 配置段，启动守护进程，并安装全局 workflow-mcp PATH 占位命令，使之后无论身处项目内何处，运行 workflow-mcp <verb> 即可执行所有命令。如果主机上已登录 Codex（~/.codex/auth.json），守护进程会以只读方式继承该登录信息，无需再次登录。除非使用 --no-web，或端口已被另一个实例占用，否则无令牌的只读仪表板会在 http://127.0.0.1:7331 启动。

希望在执行任何操作前手动验证发布者证明和校验和的运维人员，应按照 SECURITY.md 中的强化引导流程操作；该流程会下载并验证同一个安装包，且不会将任何内容通过管道传给 shell。

安装会创建 <project>/.workflow-mcp/，在 <project>/.codex/config.toml 中写入一个带标记的项目本地 Codex MCP 配置段，拉取由摘要固定的镜像，并记录稳定的实例、Compose 项目、Docker 上下文、Docker Engine ID 指纹、项目和命名卷身份信息。特定于机器的文件会被 gitignore。在默认配置中，Agent 可以读取挂载的整个项目，但受管理的 Codex 权限配置目前仅允许在 .claude/workflows 下写入（即创作子树）——项目绑定挂载在容器层面可写，但策略会拒绝 Agent 修改其他项目文件的指令，因此目前无法成功执行会重写源代码的工作流。有意将 Agent 的写入范围扩展到项目其余部分的工作已推迟到单独进行威胁建模的可写子树配置中（Agent 是可被提示词注入的大模型，因此扩大其权限范围并非默认选项）。与此同时，容器根文件系统仍保持只读，守护进程仍以 UID/GID 10001:10001 运行，/data 和每个密钥挂载仍无法由 Agent 命令读取，项目 .codex 目录仍保持屏蔽。使用 --hardened 安装即可恢复最初发布时的安全状态：只读项目绑定挂载、启动时/持久化源代码批准、令牌保护的 Web 界面，以及隔离的仅容器内凭据，所有设置都由一个已记录的配置位控制。

如果 config.toml 由其他配置管理器管理，请使用 --no-codex。在镜像内运行 instance codex-config，即可生成完全一致的配置段以供恢复。

身份验证

如果主机上已有 Codex 登录信息，守护进程会继承该信息，你完全不需要登录 — workflow-mcp doctor 和 auth status 会报告 Authenticated。只有在主机上没有可用凭据时，才运行：

workflow-mcp auth login

这会使用 Codex 的设备码流程，你的 ChatGPT 账户必须允许此流程 — 如果在 ChatGPT 安全设置中禁用了设备授权，此命令就会失败，直到你启用该功能（或在安装时通过 --api-key-file 提供 API 密钥）。继承主机登录信息的路径可以完全避免这一流程。

这是由容器持有的 Codex 设备登录：它会输出一个 URL 和验证码，并将真实凭据写入容器自己的 Codex 主目录。它始终有效，而且容器登录信息始终优先于继承的任何信息。

继承主机登录信息是尽力而为的便利功能，而非保证。安装时会检测 ~/.codex/auth.json（遵循 CODEX_HOME），并将其以只读方式挂载，作为容器可写 Codex 主目录的初始凭据；如果该初始凭据可用，你就完全不需要登录。但主机上的 ChatGPT/订阅登录信息还包含该文件之外的账户和配置状态，因此即使初始凭据复制成功，容器中的 Codex 仍可能无法进行身份验证。因此，守护进程会通过询问 Codex 本身来验证继承的凭据，而不会仅凭文件可读就认定“已配置” — auth status 会如实报告状态；如果无法进行身份验证，解决方法就是运行上面的 auth login。安装时使用 --no-host-auth 可完全跳过检测；--hardened 也会禁用继承。

对于明确的非交互式路径，将密钥单独放在一个普通的非符号链接文件中，并在安装时绑定其绝对路径（明确指定的 API 密钥始终优先于继承的主机登录信息）：

umask 077
printf '%s\n' "$OPENAI_API_KEY" > /absolute/private/openai-api-key
# Native Linux only: local Compose secrets retain host ownership. Grant the fixed runtime identity
# read access to this one file without broadening its mode; Docker Desktop normally needs no ACL.
setfacl -m u:10001:r /absolute/private/openai-api-key
./workflow-mcp-bundle/workflow-mcp-docker install /absolute/project \
  --api-key-file=/absolute/private/openai-api-key
/absolute/project/.workflow-mcp/workflow-mcp-docker up

Compose 会将该文件呈现为 /run/secrets/openai_api_key；它不会被复制到安装目录、运行记录、日志或备份中。删除或轮换主机上的文件会影响下次容器启动。

交互式设备登录由守护进程负责；工作流运行期间会拒绝更改账户：

./workflow-mcp-docker auth status
./workflow-mcp-docker auth login
./workflow-mcp-docker auth logout

登录流通过私有管理 Unix 套接字传输。不要通过单独的 docker compose exec 调用 codex login：这会在共享的 Codex 主目录中创建一个未经协调的写入者。

使用 Codex MCP

生成的 Codex 配置段会运行已安装的、限定于项目的启动器：

/absolute/project/.workflow-mcp/workflow-mcp-docker mcp-proxy

启动器会重新验证实例/上下文身份，并在进入代理前重建每个已记录的 Compose 覆盖配置。代理会将 stdout 专用于 MCP JSON-RPC，并使用命名卷中存储的 MCP 令牌向回环守护进程进行身份验证。它提供十四个工具：

• workflow_list、workflow_author_guide、workflow_describe 和 workflow_validate 用于发现定义并指导编写；
• workflow_run、workflow_resume 和 workflow_run_cancel 用于更改持久化运行状态；
• workflow_run_status 和 workflow_run_events 用于通过严格游标跟踪运行；以及
• 五个结果/Agent 工具，用于分页查看完整工作流和各 Agent 的证据，不包含文件系统路径。

workflow_run 会立即返回。从返回的游标开始持续轮询 workflow_run_events，或读取 workflow_run_status；MCP 传输的生命周期不等于运行的生命周期。

终端和浏览器界面

终端 UI 和状态命令是守护进程的只读客户端：

./workflow-mcp-docker status
./workflow-mcp-docker status --json
./workflow-mcp-docker ui

交互式 UI 使用 1–5 或 Left/Right，在运行记录、工作流结果、Agent 结果、转录和诊断信息之间切换。使用 Up/Down 选择或滚动；在运行列表视图之外，使用 [/] 更改所选运行记录；使用 Tab/Shift-Tab 切换 Agent；使用 n/p/g 分别跳至下一页、保留的上一页和第一页。清单、结果和转录游标会保留固定的 32 条历史记录；内存中仅保留当前内容页。ui --snapshot 是非交互式、非 ANSI 的备用方案。

浏览器 UI 默认开启：打开 http://127.0.0.1:7331，仪表板无需令牌即可加载。取代 bearer 的机制不可见且不产生额外负担：端口仅绑定到环回地址，拒绝外部 Host 标头（从而防止 DNS 重绑定——重绑定后的名称会携带攻击者的 Host），拒绝跨站点 Origin，API 仅支持 GET，而且根本没有取消、审批、身份验证、令牌轮换、备份或项目写入路由需要保护。清单、结果和转录控件通过有界 API 响应分页，并替换当前内容页，而不是不断累积无限增长的 DOM 转录。使用 install --web-port=PORT 选择端口，使用 --no-web 关闭；在 --hardened 模式下，Web API 会再次要求 token --purpose=web 生成的 bearer，页面收到 401 时会显示令牌表单。

发布 Web 端口要求 Docker Engine 28.3.3 或更高版本，因为较早版本的引擎存在环回端口发布绕过问题。低于此版本要求的显式 --web-port 会被拒绝；默认开启 Web 的检测则会降级为不启用 Web UI，并提示升级。基础、终端和 MCP 操作不会发布主机端口，也不受此 Web 专属版本要求限制。

配置档案：default 和 hardened

默认配置档案面向在个人电脑上独自使用的用户。启用创作功能：Codex 可以通过内联 script 调用 workflow_run，源码会保存在项目的 .claude/workflows 下，并立即运行——Agent 写入工作流与执行工作流之间没有审批命令，因为操作人员是在自己的项目中启动此 MCP，而工作流也是其 Agent 自己生成的。MCP 服务说明会在连接时提供完整的创作格式，因此新客户端无需示例文件即可了解 DSL。

--hardened 会通过单个已记录的标志恢复原有的审查机制：

• 源码为只读。守护进程启动时，会根据规范身份和精确的 SHA-256 字节校验已存在且可见的 .claude/workflows/*.js 文件；内联 MCP 源码会在执行任何项目文件系统操作之前以 authoring-disabled 失败。与 --authoring 结合使用，可启用范围有限的可写 .claude/workflows 覆盖层：启动器会拒绝重定向路径，并要求镜像中的 UID 10001 创建、fsync、重命名、目录 fsync 并删除一个探测文件，然后才启用该功能（在原生 Linux 上，为该目录向 UID 10001 授予 ACL；产品不会通过以 root 身份运行来解决此问题）。

• hardened 模式下创作的源码永远不会自行审批。首次 MCP 调用会持久化一个禁止覆盖的定义，并返回 source-approval-required；操作人员审查其字节后，运行：

  ./workflow-mcp-docker source approvals --json
  ./workflow-mcp-docker source approve --name=my-workflow --source-hash=<64-hex-source-hash>
  

  守护进程会重新读取当前可见的工作流，并拒绝不匹配的内容。持久化记录仅包含经过哈希处理的规范身份、项目哈希、工作流名称、源码哈希和时间戳。哪怕只编辑一个字节，也会撤销授权；复制或还原属于其他项目身份的记录也不会授予执行权限。

• 项目挂载恢复为只读，Web API 恢复为 bearer 令牌身份验证，Codex 凭据继续与容器隔离（绝不会读取主机的 auth.json）。

备份、恢复和升级

第一版备份采用离线方式，不包含任何凭据和本地令牌：

./workflow-mcp-docker backup create --output=/absolute/backups/project.backup
./workflow-mcp-docker backup verify --input=/absolute/backups/project.backup

备份特意采用离线方式，不会自动重启实例。归档文件和校验和成功提交后，运行 ./workflow-mcp-docker up 以恢复服务。

backup create 会正常停止守护进程，重新验证确切的已标记卷，并从固定的镜像启动一个无网络的一次性容器。它会获取同一个内核所有者锁，且不会挂载项目、Docker 套接字或凭据。它会写入：

• project.backup：采用 gzip 压缩、带帧的 v1 归档，包含清单和每个条目的 SHA-256；以及
• project.backup.sha256：外层校验和／提交记录，最后发布。

负载包含布局 v1、运行存储、配置、源代码审批和工作区。 它排除 .coordination、codex-home、secrets、backups、tmpfs、缓存和暂存状态。 verify 会检查外层校验和、帧格式语法、排序后的路径、条目数、允许的根目录、 私有模式、普通文件／符号链接策略、每项内容哈希、布局以及实例／项目身份，且不会解压。

恢复不会覆盖数据，且仅支持相同身份：

./workflow-mcp-docker restore --input=/absolute/backups/project.backup
./workflow-mcp-docker up
./workflow-mcp-docker auth login       # interactive mode; or configure the API-key file before up

启动器会将私有主机归档文件及其附属文件复制到一个临时 Docker 卷，将它们的权限收紧为 UID 10001／模式 0400，并从同一快照进行验证和恢复。这既可避免原生 Linux 上绑定挂载的权限错误，也可避免验证后主机文件被替换的时间窗口。只有验证完成后才会打开目标卷，且目标卷必须是新卷，或仅包含经审查的空镜像骨架和协调锁。失败或中断的部分解压会留下非空目标，恢复操作会拒绝使用该目标。保留实例身份，并且仅在重试前重置经过验证的目标：

./workflow-mcp-docker restore reset-target --confirm=INSTANCE_ID
./workflow-mcp-docker restore --input=/absolute/backups/project.backup

令牌会在守护进程首次启动时重新生成，并且必须重新进行交互式身份验证。

使用较新的已验证发行包进行升级：

./new-workflow-mcp-bundle/workflow-mcp-docker upgrade /absolute/project

启动器会拒绝降级，保留实例／项目／卷身份，停止旧守护进程，以原子方式替换公开的发行包文件和镜像字段，并等待服务就绪。对于 v1 布局，如果新守护进程启动失败，它会恢复先前的发行包／镜像。请先创建离线备份；启动器事务可应对进程中断，而主机断电后的恢复则依赖该备份。未来发行版的说明若声明需要迁移布局，则可能要求进行迁移，并可能限制回滚。

检查所选格式，但不对其进行更改：

./workflow-mcp-docker migrate inspect --json

关闭、移除和恢复

down 会要求守护进程进入静默状态，拒绝新的变更，等待已接纳的写入者完成，持久中断正在运行的任务，终止受约束的 Codex 尝试，关闭 MCP/管理传输，并释放内核锁。随后，Compose 会移除容器和网络，但保留命名卷。

./workflow-mcp-docker down
./workflow-mcp-docker uninstall

卸载会移除带标记的 Codex 配置段和公开的 .workflow-mcp 文件，但会保留持久数据。在所有受支持的主机上，执行中的启动器是唯一无法安全移除的文件。命令返回后，移除该启动器文件，再移除现在为空的所属目录；不要递归删除 .workflow-mcp。命令会打印保留的 UUID；只能从相同的规范项目路径、Docker context 和同一个 Docker daemon，使用全新且已验证的 bundle 重新关联：

rm /absolute/project/.workflow-mcp/workflow-mcp-docker
rmdir /absolute/project/.workflow-mcp
./new-workflow-mcp-bundle/workflow-mcp-docker install /absolute/project \
  --adopt-instance=<preserved-instance-uuid>

在 Windows 上，先移除确切的 workflow-mcp-docker.ps1 残留文件，再移除空的 C:\absolute\project\.workflow-mcp 目录，然后运行全新 bundle 中的 PowerShell 启动器。

接管时会推导出原始的 Compose/卷名称，重新计算规范项目哈希，并要求驱动程序/选项/实例/项目/daemon 指纹标签完全匹配后，才写入安装元数据。Context 名称和套接字不会被视为引擎身份：如果相同路由背后的 Engine 已重置，操作会安全失败。移动项目或复制 UUID 都会安全失败；v1 不支持自动跨路径/context/daemon 迁移。永久删除是单独的、需检查标签的命令，并要求提供确切的实例 UUID：

./workflow-mcp-docker uninstall --delete-data --confirm=<instance-uuid>

<instance-uuid> 由 instance.json 打印；此命令会永久删除运行记录、结果、审批、令牌，以及容器所属的登录信息，且无法撤销，除非有备份。

如果已安装的便捷启动器丢失，请解压相同版本且已验证的发布 bundle，并让其中的启动器恢复实例。源 bundle 启动器接受项目路径，使用固定的镜像严格解析已安装的身份信息，将每个可执行的已安装 Compose 文件与该镜像中的不可变字节进行比较，重新验证卷/context/daemon，并重建所有必需的 .codex 屏蔽项、Web、创作和 API 密钥覆盖配置：

gh attestation verify workflow-mcp-install-<version>.tar.gz \
  --repo Juliusolsson05/workflow-mcp
tar -xzf workflow-mcp-install-<version>.tar.gz
(cd workflow-mcp-install-<version> && sha256sum --check SHA256SUMS)
./workflow-mcp-install-<version>/workflow-mcp-docker up /absolute/project

直接运行 docker compose ... up 并非受支持的恢复捷径：基础文件缺少实例专属的隔离/身份验证/创作/Web 覆盖配置，而且手动重建的环境未经主机证明。原始 Compose 仅限用于离线 config 诊断；切勿从该诊断模型运行提供方。不要为现有卷创建新的身份。

资源配置

受支持的默认配置是同时运行一个 Codex 尝试；Compose 硬限制为 1 CPU、2 GiB 内存、512 个 PIDs、64 MiB 共享内存和 256 MiB 临时空间。就绪检查会检查有效的 cgroup 限制；如果这些限制不足以支持配置的并发数，就会拒绝启动。每增加一个并发尝试，除守护进程基准所需的 1 GiB 内存外，还需要额外增加 1 CPU 和 1 GiB 内存；请同时提高 WORKFLOW_MCP_CONCURRENCY、WORKFLOW_MCP_CPUS 和 WORKFLOW_MCP_MEMORY_LIMIT。Docker Desktop 也必须为其 Linux VM 分配至少这些限制。Docker MCP Catalog 模板会有意将并发数固定为 1，因为其文档中规定的每服务配置为 1 CPU/2 GiB。

支持矩阵

环境	基础只读模式	Web	编写	声称支持前所需的证据
Linux Engine、本地上下文、本地命名卷	允许嵌套用户命名空间时为发布目标	Engine 28.3.3+	需要通过 UID-10001 探测/ACL 验证	原生 amd64/arm64 最终镜像发布门槛
Rootless Linux Engine	有条件的目标	Engine 28.3.3+	UID 映射必须通过验证	重置干净的 rootless 运行器
Docker Desktop macOS、Intel/Apple Silicon	发布目标	Engine 28.3.3+	绑定探测必须通过	每种架构都需使用重置干净的 Desktop 运行器
Docker Desktop Windows + PowerShell，仅限本地驱动器	预览目标（不支持 UNC）	Engine 28.3.3+	继承当前用户的项目 ACL + 绑定探测	重置干净的 Windows/Desktop/PowerShell 运行器
远程 Docker 上下文、Kubernetes、带选项/远程卷	v1 不支持	否	否	启动器会拒绝

“发布目标”并不代表尚未发布或未经资格验证的构建已获支持。只有当稳定版本的发布证据符合 docs/PLATFORM_VALIDATION.md 时，才能将相应行标记为支持；证据缺失时应缩小发布 矩阵，而不能据此作出假设。

持久性断电保证仅适用于 Docker 普通的本地命名卷文件系统，并且仅在文件 fsync、同一文件系统内的原子重命名和目录 fsync 具有文档所述语义时成立。 网络文件系统和 Docker 卷插件不会被默认视为等效。Windows 和 macOS 指 Docker Desktop 下的 Linux 容器，而非原生 Windows 镜像。

安全模型

• 最终镜像以非 root 用户运行，移除所有功能，启用 no-new-privileges，使用只读的 根文件系统/项目目录、有界 tmpfs、PID 限制，并且不包含 Docker 套接字。其运行时会禁用 Docker 自带的 seccomp 和 AppArmor 配置文件，仅因为它们会阻止 Bubblewrap 设置；随后必须由真正的恶意探测 证明范围更窄的 Codex 命令沙箱能够启动并正常运行。
• 受管 Codex 权限配置文件会拒绝访问 /data、/run/secrets、/run/workflow-mcp 和 /proc； 工具没有网络，并在 Codex 的 Bubblewrap PID 命名空间内启动。
• 镜像诊断程序会运行恶意最终镜像探测，尝试读取 MCP 令牌并启动一个脱离终端的 setsid 休眠进程。只要任一项逃逸，发布即失败。
• 项目中的 .codex 会被屏蔽，提供方的尝试会使用 --ignore-user-config/--ignore-rules，并禁用应用、插件、图像生成和多 Agent 委派。AGENTS.md 仍是普通项目提示词输入；它不具备可执行配置权限。
• MCP、Web 和管理员令牌彼此独立。管理员访问使用 tmpfs 中权限为 0600 的 Unix 套接字和令牌，且无法从受管 Agent 沙箱访问。
• 浏览器会验证 Host、Origin、承载令牌受众、CSP 和不可变的内容哈希资源，并且仅公开 GET 方式的投影数据，不包含绝对项目路径。

守护进程和 Codex 共用容器 UID，因此不会声称仅凭 Unix 模式位就能隔离 Agent。边界由受管挂载/PID/网络策略及其恶意探测共同构成。请参阅 SECURITY.md 和 docs/adr/0001-runtime-topology.md。

诊断和退出行为

./workflow-mcp-docker doctor
./workflow-mcp-docker logs
docker compose exec -T workflow-mcp workflow-mcp doctor --json

启动器会输出一份带版本的 {host, container, identityVerdict} 报告，涵盖 Docker 和 Compose 版本/上下文、规范实例/项目标识、卷标签/选项、渲染后的 Compose 配置、映像/核心/Codex/MCP 版本、挂载访问权限、Codex 策略探测、所有者启动后的守护进程就绪状态、布局、可用空间，以及提供方身份验证（不会调用计费模型）。独立的客户端进程无法直接检查守护进程继承的锁描述符；精确的双所有者互斥是发布/容器冒烟测试的门槛，不属于诊断程序的声明。健康检查端点较为粗略，且未经身份验证；诊断信息绝不会打印令牌或凭据值。容器 CLI 对无效用法/配置使用退出码 2，对必需服务不可用使用 3，对身份验证失败使用 4，对源/身份验证策略拒绝使用 5，对内部错误使用 10。主机启动器是编排脚本：自身的验证失败使用 1，完成诊断报告且 ok:false 时使用 3，其他 Docker/Compose 错误可能保留对应子进程的非零结果。需要其余类型化退出码的自动化程序应在运行中的容器内调用 workflow-mcp。

常见故障：

• another durable workflow owner：查找完全相同的实例/卷；不要删除其锁。
• Docker context changed：切回记录的本地上下文；采用操作绝不会绕过此检查。
• Docker daemon changed：路由背后的 Engine ID 已改变；v1 绝不会跨守护进程导入保留的状态，即使上下文和端点字符串未变。
• UID 10001 cannot durably author：仅为 .claude/workflows 授予适当的 ACL，或保持只读。
• project .codex configuration：确保已提供生成的屏蔽覆盖配置，然后重启。
• source-approval-required：检查并批准当前的准确哈希，然后按名称/路径重试。
• layout newer：使用较新的映像；降级操作无法推断未来状态。

从源代码构建和测试

维护者必须先完成外部发布先决条件，才能创建首个稳定标签。只要任何由项目所有者控制的设置或平台资格认证尚未完成，该仓库就不会进入可发布状态。

npm ci --include=dev
npm run check
npm --prefix standalone ci --include=dev
npm --prefix standalone run check
docker build -f standalone/docker/Dockerfile -t workflow-mcp:development .
standalone/scripts/container-smoke.sh workflow-mcp:development

此外，发布工作流会各构建一次原生 linux/amd64 和 linux/arm64 成员，附加最大级别的 BuildKit 来源证明和 SBOM，按文档规定的阈值进行扫描，对索引摘要进行无密钥签名，验证每个推广标签均指向该摘要，为发布资产生成证明，发布不可变的 GitHub 发布版本，并执行无需检出代码的安装冒烟测试。

注册表模式

distribution/mcp-registry/server.json 是官方 MCP Registry OCI 记录。对于此通用软件包界面，映像默认使用会话绑定的 STDIO；如果通用运行器暴露了未屏蔽的项目 .codex 目录，则会以关闭方式拒绝提供方调用。distribution/docker-catalog 包含一个发布模板，该模板仅接受未配置 .codex 的项目，避免其他 Catalog 容器修改全局共享的屏蔽配置；模板还明确列出其局限：Docker MCP Catalog 无法提供长时间运行的守护进程生命周期、Web/TUI 控件、主机创作探测、交互式身份验证代理或离线维护启动器。如果需要在 MCP 客户端断开连接后仍保持持久性，请使用带校验和的 Compose 软件包。

独立软件包有意隔离在此目录下。与提供方无关的核心绝不会导入 Docker 守护进程、UI、发布、凭据或注册表层。