Workflow MCP

Workflow MCP スタンドアロン

Workflow MCP は、Agent Code を必要とせずに、Claude 互換の JavaScript ワークフロー定義を、Codex を基盤とする永続的な MCP ジョブとして実行します。Docker がランタイム、Codex CLI、認証情報、状態、プロセス分離を管理するため、通常の運用ではホストに Node.js、Codex、Agent Code をインストールする必要はありません。ホストのランタイムには、ローカルの Docker Engine または Docker Desktop と Compose が必要です。検証済みリリースのブートストラップには、GitHub CLI (gh)、tar、sha256sum または shasum、POSIX シェルも必要です。Windows では、PowerShell 7 と、対応する組み込みのアーカイブ／ハッシュコマンドを使用します。

Codex の Linux Bubblewrap 境界には、Docker ホストで非特権ユーザー名前空間が必要です。Docker Desktop は、この機能を Linux VM で提供します。ネイティブ 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 のセキュリティに関する注意事項を参照してください。

通常のインストールでは、プロジェクトごとに長時間稼働するデーモンを 1 つ使用します。Codex は docker compose exec で小さな STDIO プロキシに接続するため、1 つの MCP クライアントが切断されても、デーモンや実行中のジョブはキャンセルされません。汎用の OCI/MCP レジストリ向けに、セッションにバインドされた STDIO イメージモードもありますが、ライフサイクルの契約はより限定的です。

インストール

対応するリリースの公開後、プロジェクトディレクトリで次のコマンドを実行するだけです。

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 の堅牢化されたブートストラップ手順に従ってください。

インストールによって <project>/.workflow-mcp/ が作成され、<project>/.codex/config.toml にプロジェクトローカルの Codex MCP 設定項目がマーカー付きで1つ書き込まれます。また、ダイジェストで固定されたイメージが取得され、安定したインスタンス、Compose プロジェクト、Docker コンテキスト、Docker Engine ID のフィンガープリント、プロジェクト、および名前付きボリュームの識別情報が記録されます。マシン固有のファイルは Git の追跡対象から除外されます。デフォルトのプロファイルでは、エージェントはマウントされたプロジェクト全体を読み取れますが、管理対象の Codex 権限プロファイルで書き込みが許可されるのは .claude/workflows（作成用サブツリー）のみです。プロジェクトのバインドマウントはコンテナ層では書き込み可能ですが、エージェントが他のプロジェクトファイルを編集するよう指示されても、ポリシーによって拒否されるため、ソースを書き換えるワークフローは現時点では成功しません。エージェントが書き込み可能な範囲をプロジェクトの他の部分にも広げることは、脅威モデルを別途作成した書き込み可能サブツリーのプロファイルで対応するため、意図的に先送りしています（エージェントはプロンプトインジェクションを受ける可能性がある LLM なので、アクセス範囲の拡大はデフォルトではありません）。一方で、コンテナのルートファイルシステムは読み取り専用のまま、デーモンは UID/GID 10001:10001 のまま、/data とすべてのシークレットマウントはエージェントのコマンドから読み取り不可のまま、プロジェクトの .codex ディレクトリはマスクされたままです。--hardened を付けてインストールすると、当初の提供時のセキュリティ設定に戻ります。読み取り専用のプロジェクトバインド、起動時および永続的なソース承認、トークンで保護された Web、コンテナ内のみで使用される分離された認証情報が、1つの記録されたプロファイル設定で有効になります。

別の設定管理ツールが 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 トークンを使ってループバックデーモンに認証します。次の 14 個のツールを公開します。

• workflow_list、workflow_author_guide、workflow_describe、workflow_validate は、定義を見つけ、作成方法を案内します。
• workflow_run、workflow_resume、workflow_run_cancel は、永続的な実行状態を変更します。
• workflow_run_status と workflow_run_events は、厳密なカーソルを使って実行を追跡します。
• 残りの 5 つの結果／エージェントツールは、ファイルシステムのパスを使わずに、ワークフロー全体およびエージェントごとのエビデンスをページ単位で取得します。

workflow_run はすぐに返ります。返されたカーソルから workflow_run_events のポーリングを続けるか、workflow_run_status を読み取ってください。MCP のトランスポートの存続期間は、実行の存続期間とは異なります。

ターミナルおよびブラウザーインターフェース

ターミナル UI と status コマンドは、デーモンの読み取り専用クライアントです。

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

対話型 UI では、1～5 または Left/Right キーで、実行、ワークフローの結果、エージェントの結果、トランスクリプト、診断を切り替えます。Up/Down キーで選択またはスクロールし、実行リスト表示以外で選択中の実行を変更するには [/] を使います。Tab/Shift-Tab でエージェントを切り替え、n/p/g で次のページ、保持されている前のページ、最初のページに移動します。在庫、結果、トランスクリプトのカーソルは固定の 32 件の履歴を保持し、メモリに保持されるのは現在のコンテンツページのみです。ui --snapshot は、対話操作や ANSI を使わない場合の代替手段です。

ブラウザー UI はデフォルトで有効です。http://127.0.0.1:7331 を開くと、トークンなしでダッシュボードが読み込まれます。ベアラー認証の代わりに使われるものは目に見えず、追加の負担もありません。ポートはループバックにのみバインドされ、外部の Host ヘッダーは拒否されます（これにより DNS リバインディングを防ぎます。リバインドされた名前には攻撃者の Host が付いて届くためです）。クロスサイトの Origin は拒否され、API は GET のみです。また、そもそも保護が必要となるキャンセル、承認、認証、トークンローテーション、バックアップ、プロジェクトへの書き込み用ルートはありません。在庫、結果、トランスクリプトの操作では、上限付き API レスポンスをページごとに表示し、上限のない DOM トランスクリプトとして蓄積するのではなく、現在のコンテンツページを置き換えます。ポートは install --web-port=PORT で選択し、--no-web で無効にします。--hardened の場合、Web API では再び token --purpose=web のベアラーが必要になり、401 を受け取るとページにトークン入力フォームが表示されます。

Web の公開には Docker Engine 28.3.3 以降が必要です。それ以前のエンジンには、ループバック公開を回避できる問題があったためです。この要件を下回る --web-port の明示的な指定は拒否されます。デフォルトで Web を有効にする際の検出では、アップグレードを促すメッセージを表示し、Web UI を無効化します。基本、ターミナル、MCP の各動作ではホストポートを公開せず、この Web 固有の最低要件も適用されません。

プロファイル：default と hardened

default プロファイルは、自分のマシンで 1 人が使うことを想定しています。オーサリングは有効です。Codex はインラインの script を指定して workflow_run を呼び出せます。ソースはプロジェクトの .claude/workflows に保存され、すぐに実行されます。エージェントがワークフローを書いてから実行するまでの間に承認コマンドがないのは、オペレーターが自分のプロジェクトでこの MCP を起動し、そのワークフローが自分のエージェントの出力だからです。MCP サーバーの指示には、接続時にオーサリング形式の全容が含まれるため、新しいクライアントが DSL を学ぶのにサンプルファイルは必要ありません。

--hardened は、記録された単一のビットから元のレビュー体制に戻します。

• ソースは読み取り専用です。既存の可視な .claude/workflows/*.js ファイルは、デーモンの起動時に正規化された識別情報と SHA-256 の完全一致で承認されます。インライン MCP ソースは、プロジェクトのファイルシステムにアクセスする前に authoring-disabled で失敗します。書き込み可能な .claude/workflows に限定したオーバーレイを使う場合は、--authoring と組み合わせてください。ランチャーはリダイレクトされたパスを拒否し、オーバーレイを有効にする前に、正確なイメージ内の UID 10001 に対して、プローブの作成、fsync、名前変更、ディレクトリの fsync、削除を要求します（ネイティブ Linux では、そのディレクトリに対する ACL を UID 10001 に付与してください。この製品は 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>
  

  デーモンは現在の可視なワークフローを再読み込みし、不一致があれば拒否します。永続レコードには、ハッシュ化された正規化済みの識別情報、プロジェクトのハッシュ、ワークフロー名、ソースのハッシュ、タイムスタンプのみが含まれます。1 バイトでも編集すると権限が取り消され、別のプロジェクト識別情報に対するレコードをコピーまたは復元しても、実行権限は付与されません。

• プロジェクトのバインドは再び読み取り専用になり、Web API はベアラートークン認証に戻り、Codex の認証情報はコンテナー内に隔離されたままになります（ホストの auth.json は読み込まれません）。

バックアップ、復元、アップグレード

バージョン1のバックアップはオフラインで行われ、すべての認証情報とローカルトークンを除外します。

./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：マニフェストと各エントリの SHA-256 を含む、gzip 圧縮されたフレーム形式の v1 アーカイブ。
• 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

ランチャーは、ホスト上のプライベートなアーカイブとサイドカーファイルを1つの一時 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 コンテキスト、同じ Docker デーモンからのみ再接続してください。

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 ディレクトリを削除してから、新しいバンドルの PowerShell ランチャーを実行してください。

引き継ぎ処理では、元の Compose／ボリューム名を導出して、正規化されたプロジェクトのハッシュを再計算します。また、インストールメタデータを書き込む前に、ドライバー／オプション／インスタンス／プロジェクト／デーモンフィンガープリントのラベルが完全に一致することを求めます。コンテキスト名とソケットはエンジンの識別情報として扱いません。同じ経路の背後で Engine がリセットされている場合は、安全のため処理を拒否します。プロジェクトを移動した場合や UUID をコピーした場合も、安全のため処理を拒否します。v1 では、パス／コンテキスト／デーモンをまたぐ自動移行はできません。完全削除には、インスタンス UUID の完全一致を求める、別途用意されたラベル検証付きコマンドを使用します。

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

<instance-uuid> は instance.json に表示されます。このコマンドを実行すると、実行履歴、結果、承認、トークン、コンテナーが所有するログイン情報が完全に削除され、バックアップがなければ元に戻せません。

インストール済みの便利なランチャーを失った場合は、同じバージョンの検証済みリリースバンドルを展開し、そのランチャーにインスタンスを復旧させてください。ソースバンドルのランチャーはプロジェクトパスを受け取り、ピン留めされたイメージを使ってインストール済みの識別情報を厳密に解析し、実行対象となるインストール済み Compose ファイルのすべてを、そのイメージ内の不変バイト列と照合します。さらに、ボリューム／コンテキスト／デーモンを再検証し、必要な .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 の試行を同時に 1 件まで実行し、Compose の上限を CPU 1 個、メモリ 2 GiB、PID 512 個、共有メモリ 64 MiB、一時領域 256 MiB に設定します。レディネスチェックでは実効 cgroup 制限を確認し、設定された同時実行数をサポートできない場合は起動を拒否します。同時実行数を 1 件増やすごとに、デーモンのベースラインである 1 GiB に加えて、CPU 1 個とメモリ 1 GiB が必要です。WORKFLOW_MCP_CONCURRENCY、WORKFLOW_MCP_CPUS、WORKFLOW_MCP_MEMORY_LIMIT をまとめて引き上げてください。Docker Desktop の Linux VM にも、これらの制限以上を割り当てる必要があります。Docker MCP Catalog のテンプレートでは、サーバーあたりの文書化されたプロファイルが CPU 1 個／メモリ 2 GiB であるため、同時実行数を意図的に 1 に固定しています。

サポートマトリックス

環境	基本の読み取り専用モード	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 に従っている必要があります。証拠がない場合は、想定で補うのではなく、リリースマトリックスの範囲を狭めます。

電源喪失時の耐久性に関する主張は、ファイルの fsync、同一ファイルシステム内でのアトミックな rename、およびディレクトリの fsync が文書化されたセマンティクスに従う、Docker の通常のローカル名前付きボリュームのファイルシステムにのみ適用されます。ネットワークファイルシステムや Docker ボリュームプラグインを、暗黙のうちに同等のものとして扱うことはありません。Windows と macOS は、ネイティブの Windows イメージではなく、Docker Desktop 上の Linux コンテナを指します。

セキュリティモデル

• 最終イメージは 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 を使用し、アプリ、プラグイン、画像生成、マルチエージェントへの委任を無効にします。AGENTS.md は通常のプロジェクトプロンプト入力のままであり、実行可能な設定権限は持ちません。
• MCP、Web、管理用のトークンはそれぞれ別です。管理用アクセスには、tmpfs 内の mode-0600 Unix ソケットとトークンを使用し、管理対象エージェントのサンドボックスからは到達できません。
• ブラウザーは Host、Origin、ベアラーの audience、CSP、変更不可能なコンテンツハッシュ付きアセットを検証し、絶対パスのプロジェクトパスを含まない、GET 専用の投影データを公開します。

デーモンと Codex はコンテナ UID を共有するため、Unix のモードビットだけをエージェントの隔離手段とはしていません。境界となるのは、管理対象のマウント／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} レポートを1つ出力します。このレポートでは、Docker と Compose のバージョン／コンテキスト、正規化されたインスタンス／プロジェクトの識別情報、ボリュームのラベル／オプション、レンダリングされた Compose 設定、イメージ／コア／Codex／MCP のバージョン、マウントへのアクセス、Codex のポリシー検証、オーナー起動後のデーモンの準備状況、レイアウト、空き容量、課金対象のモデル呼び出しを伴わないプロバイダー認証を確認します。別プロセスであるクライアントからは、デーモンが継承したロック記述子を直接検査できません。正確な2オーナー排他制御の確認は、リリース／コンテナーのスモークテストゲートであり、doctor の検査対象ではありません。ヘルスエンドポイントは概略的なもので、認証されていません。診断でトークンや認証情報の値が出力されることはありません。コンテナーの CLI は、無効な使用法／設定に 2、必須サービスを利用できない場合に 3、認証エラーに 4、ソース／認証ポリシーによる拒否に 5、内部エラーに 10 の終了コードを使用します。ホストランチャーはオーケストレーションスクリプトです。ランチャー自体の検証失敗には 1、ok:false を含む doctor レポートの完了には 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、リリース、認証情報、レジストリの各レイヤーをインポートしません。