mcpField
C
codex-background

codex-background

github.com/amelnagdyエージェントワークフロー2.5k531 回インストール2 週間前に更新
リポジトリ

codex-background について

Codex で MCP サーバー経由のタスク委任を行い、完了までリクエストを待機させる支援スキルです。登録済み委任スキルの設定、実行、待機、復旧、レビューの手順を定めます。

主な機能

  1. 01委任スキル設定の初期化
  2. 02delegate_run による実行依頼
  3. 03状態ポーリングなしの待機
  4. 04中断後の待機と復旧
  5. 05実行結果と成果物レビューの分離

活用シーン

  1. 01Codex のバックグラウンド委任設定
  2. 02承認済みタスクの委任実行
  3. 03中断後の待機再開
  4. 04変更を取り込む前の結果レビュー

MCP 対応

MCP サーバーの delegate_run、delegate_wait、delegate_abort ツールを使い、委任タスクの実行、待機、明示的な中止を行います。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/amelnagdy/delegate-skills --skill codex-background

インストール後、Claude Code で/codex-backgroundを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
configuration.md
scripts/
bootstrap.mjs
bootstrap.test.mjs
linux-owner.c
server.mjs
server.test.mjs
supervisor.mjs
windows-job.cs
windows-job.ps1

詳細

Codex のバックグラウンド委任

このサポートスキルは、Codex が待機する境界を変更します。選択した委任スキルは引き続き、ブリーフ、プロバイダー引数、権限、結果の解釈、レビュー、ゲート、反映を担当します。 Claude のバックグラウンド Bash ワークフローは変更されません。サポートユーティリティは別途インストールされ、codex-delegate の依存関係として暗黙にインストールされることはありません。詳細：references/configuration.md。

初回使用／セットアップ

delegate_run ツールが利用できない場合、セットアップは未完了です。ブートストラップによって $CODEX_HOME/config.toml（既定値は ~/.codex/config.toml。先にバックアップされます）が更新され、インストール済みの *-delegate スキルのレジストリが書き込まれることをユーザーに伝えてから、次を実行します。

node "<skill-dir>/scripts/bootstrap.mjs"

<skill-dir> は、このスキルのインストール先ディレクトリ（このスキルの SKILL.md があるフォルダー）です。ワークスペースの外部に書き込むため、Codex に必要な承認またはサンドボックスの拡張を求めてください。出力を報告してから、Codex を再起動する（または MCP サーバーを再読み込みする）ようユーザーに依頼してください。その後、ツールが表示されます。 ブートストラップが失敗した場合は、その失敗を報告してください。シェルによるポーリングに切り替えてはいけません。委任スキルを追加でインストールした後は、もう一度実行してください。node "<skill-dir>/scripts/bootstrap.mjs" --check は、書き込みを行わずにセットアップを検証します。

手順

  1. 選択した委任スキルに従って、自己完結したブリーフと承認済みのワークスペースを準備します。 ブリーフは、codex-background ディレクトリ内の briefs/ ディレクトリ（$CODEX_HOME/codex-background/briefs/<runId>.txt）に書き込み、隣接する runs/<runId> を outputDirectory として使用するか、サーバーの指示に記載されたパスに従ってください。サンドボックスからそこに書き込めない場合は、承認済みのワークスペース内にブリーフを置くこともできます。ブリーフから渡されたリレーパスは、決して受け入れないでください。
  2. 設定済み MCP サーバーの delegate_run を、一意の runId、登録済みの実装者キー、絶対パスで指定したブリーフ／ワークスペース／outputDirectory、明示的な relayTimeoutSeconds、プロバイダー固有の relayArgs を使って、正確に 1 回呼び出します。共通の引数は構造化フィールドに入れ、プロバイダー固有の引数は変更せずに渡してください。再開識別子は不透明な値として扱います。
  3. 完了するまで、その MCP リクエストを保留状態に保ちます。モデル主導のスリープ、ステータス、ログのポーリングは使用しないでください。早期に結果を返して待機のために推論を再開するツールランナーでラップしてはいけません。
  4. 返されたアダプターの結果を resultText とは別に確認します。後者は変更されていない result.json の内容です（非 UTF-8 バイトの場合のみ base64）。選択したスキルを使って解釈してください。アダプターが完了したということは、リレーがゼロで終了してファイルを生成したという意味であり、そのレポートが正しい実装を証明するわけではありません。差分を確認し、ゲートを再実行して、既存の承認の範囲内で反映してください。

待機が中断された後は、同じ runId で delegate_wait を呼び出してください。再ディスパッチしてはいけません。 MCP のキャンセルは待機を切り離すだけで、承認済みのジョブは実行中のままです。終了が明示的に意図されている場合に限り、delegate_abort を使用してください。サーバーを正常にシャットダウンすると、そのサーバーが所有するジョブは中止されます。 サーバーのクラッシュ後、未解決の状態は recovery_required として返されます。保持されたアーティファクトと、実装者自身の復旧ワークフローを使って実装者を確認してください。永続化された PID を引き継いだり、強制終了したりしてはいけません。

ホストに設定されたツールのタイムアウトは、リレーのタイムアウトを 30 秒以上上回る必要があります。 サーバーは宣言された予算を検証しますが、ホストの実際の設定は強制できません。フィクスチャープロトコルテストで確認できるのは、保留中のリクエストが 1 件で中間メッセージがないことです。Codex Desktop のトークン使用量を測定したものでも、ホストが無期限に待機することを保証するものでもありません。

コメント

Markdown 対応