タスク管理（CLI）

cockpit taskは、AIエージェントや利用者がCockpitのタスクを作成し、状態を読み、次の指示を送り、結果を回収するためのCLIです。一件の仕事を別タスクへ委任する場合は、このページの流れを使います。依存関係付きの処理をYAMLで再利用する場合はFleetを選びます。

createとrunを使い分ける

別タスクの結果が次の判断に必要ならrunを使います。作成後すぐ別の作業へ進み、あとで一覧から確認するならcreateを使います。

cockpit task run \
  --instruction "変更を調査し、原因と確認結果を報告してください" \
  --directory /path/to/repo \
  --agent-type codex

長い指示、Markdown、引用、バッククォート、$を含む指示はシェル引数へ埋め込まず、--stdinまたは--instruction-fileで渡します。

cockpit task run --instruction-file instruction.md \
  --directory /path/to/repo \
  --agent-type codex

createが成功すると、作成したtaskIdと実際に選ばれたアカウントが返ります。runも、タスク作成後に最初のレポート取得がタイムアウトまたは待機エラーになった場合は、ok: trueとdata.taskIdを保持して返します。この場合、タスクはすでに存在するため同じ指示を再実行せず、返されたIDでtask getまたはtask waitを使ってください。ok: falseはタスク作成自体の失敗を示します。

スマートルーティングで作成する

AGIラボ会員としてCockpitへサインインしている場合は、createまたはrunへ--smart-routingを追加すると、登録済みのルーティング方針と指示からエージェント、モデル、推論レベルを自動選択できます。--directoryと--projectをどちらも省略すると、新規タスク画面の「自動」と同じ候補から作業場所も選びます。どちらかを指定すると作業場所だけを固定し、その中で実行条件を選びます。作成された外部エージェントのタスクはネイティブUIとAutoアカウントを使います。

cockpit task run \
  --instruction-file instruction.md \
  --smart-routing

cockpit task create \
  --instruction "このリポジトリのテスト失敗を調査してください" \
  --directory /path/to/repo \
  --smart-routing

候補は、この端末でインストール済みかつオンになっているエージェントと、取得できたモデルに限られます。TerminalとCreative Studioは選びません。--smart-routingはエージェント、モデル、推論レベルを選ぶため、これらを固定するオプションやアカウント、UIモード、system prompt、分岐元などとは併用できません。--worktreeを使う場合は--directoryまたは--projectで作業場所を固定してください。方針とサインインはこの端末に属するため、--hostには対応しません。

選択前にモデル取得を最大20秒、ルーティングを最大25秒待つ場合があります。選択に失敗した場合は固定のエラーcodeを返し、タスクを作成しません。成功時はdata.smartRoutingとタスク本体のフィールドで、選ばれたエージェント、モデル、推論レベル、必要な場合は作業場所を確認できます。正確な競合オプションとエラーコードはcockpit taskリファレンスを参照してください。

作成応答が失われた場合

task createとtask runは作成ごとに一意の作成キーを送り、送信後に接続が切れた場合は、同じキーですでに作成されたタスクを先に照合します。見つかったタスクはdata.replayed: trueと同じtaskIdで返るため、応答だけが失われても重複作成しません。未作成とCockpitが確認できた場合だけ同じキーで作成を再試行します。

task_create_interruptedはタスクが作成されていないことを確認済みで、同じコマンドを再実行できます。task_create_outcome_unknownは結果を確認できず、タスクが存在する可能性を示します。この場合は新しく作成する前にcockpit task listを確認してください。作成キーの記録は実行中のCockpitが10分間保持するため、アプリの再起動後は同じキーでも既存タスクを照合できません。

通常はCLIがUUIDを生成します。外部処理と対応づける場合だけ、英数字と.、_、:、-からなる1〜128文字を--create-keyへ指定できます。同じ呼び出し元から同じキーを再送すると同じタスクを返します。

cockpit task create \
  --instruction "公開状態を確認してください" \
  --directory /path/to/repo \
  --create-key deploy-2026-09-05-1

プロジェクト、作業フォルダ、実行設定を決める

--project <id|name>でタスクをプロジェクトへ割り当てます。--directoryを省略すると、そのプロジェクトのプライマリフォルダから開始します。--directoryも指定する場合は、そのプロジェクトに登録済みのフォルダでなければなりません。--projectを省略した場合は、作業フォルダに基づくプロジェクト規則で自動的に割り当てます。両方を省略すると、どのプロジェクトにも属さないOSの一時フォルダで始まります。Git Worktreeを分離する場合は--worktreeを使います。

エージェント、UIモード、モデル、推論レベル、アカウント、承認モード、Browser Identityはタスクごとの実行条件です。Claude Code、Codex、Antigravity、Cursor、Qoder、Grok Buildでは、--ui-mode visualまたは--ui-mode terminalで作成時の表示モードを指定できます。Cockpit AgentとTerminalはUIモードを切り替えられません。対応しない組み合わせはエラーになり、無言で別設定へ切り替わりません。特に外部サイトを扱うタスクでは、必要なログイン状態を持つBrowser Identityを明示します。

CodexのネイティブUIでは--service-tier standard|fast|ultrafastを指定できます。fastとultrafastは、選択したモデルがそのtierを提示する場合だけ有効です。

--approval-modeにはsupervised、accept-edits、auto、full-accessを指定できます。Cockpit AgentとネイティブUIのエージェントで、そのタスクだけの既定値を上書きします。ターミナルUIとTerminalタスクは対応しません。

auto（自動審査）はClaude、Codex、GrokのネイティブUIで利用でき、エージェント自身がコマンドや編集を審査します。通常の操作を許可し、危険な操作を止めるか、人の承認へ回します。質問やAskには回答しません。ほかのエージェントはautoを受け付けません。Claudeでは変更が即時に、Codexでは次のターンから適用されます。Grokは待機中のセッションを再起動して会話を保持しますが、処理中や承認・質問待ちの変更は拒否します。ClaudeやCodexでモデル・アカウント・組織の制約により自動審査が使えない場合は、実際のモードを表示してチャットで通知します。Grokの実行モードは読み戻せないため、この確認の対象外です。フルアクセスへ自動的に切り替わることはありません。

cockpit task create \
  --instruction "管理画面の公開状態を確認してください" \
  --directory /path/to/repo \
  --agent-type codex \
  --ui-mode visual \
  --media ./expected-screen.png \
  --browser-identity work

--mediaはローカルファイルをCockpitの管理領域へコピーして最初の指示へ添付します。最大8件、1件512MB、JSONは25MB、合計1GBまでです。リモートURLと、選んだエージェントが直接受け取れないファイル種別は拒否されます。元ファイルは移動も削除もされません。

プロジェクトを作成し、タスクを移動する

cockpit project create --name "Shop" --folder ~/repos/shop-web --folder ~/repos/shop-api
cockpit project update Shop --primary-folder ~/repos/shop-api
cockpit task project <task-id> Shop
cockpit task project <task-id>

cockpit projectはDesktopとPWAに表示される同じプロジェクトを管理します。先頭のフォルダがプライマリです。--folderなしでプロジェクトを作ると、Cockpitが空の管理フォルダを用意します。更新ではフォルダの追加・削除・置換・並べ替えができ、プロジェクトを削除してもフォルダは残り、タスクは「プロジェクトなし」へ移ります。

cockpit task project <task-id> <id|name>は、タスクとすべての子タスクを移動します。新しいプロジェクトのフォルダは、エージェントセッションが次に開始するときに反映されます。Master AgentとCreative Studioのタスクは移動できません。同じ名前のプロジェクトが複数ある場合は、cockpit project listで確認したIDを使います。

親子タスクを作る

タスク内から作成したタスクは、既定で呼び出し元の子タスクになります。別の親を明示する場合は--parent-task-id、親なしの独立したタスクを作る場合は--top-levelを使います。task createとtask runの両方で指定でき、省略した場合は従来どおり呼び出し元が親になります。

cockpit task create --top-level --instruction "プロジェクトのバックログを管理してください"
cockpit task run --top-level --instruction "プロジェクトを独立してレビューしてください"

--top-levelと--parent-task-idは同時に指定できません。空文字や空白のみの親IDは拒否されます。親なしで作る場合は--top-levelを使ってください。作成元の監査情報（createdByTaskId）は親子関係（parentMasterId）とは独立して保持されます。Hooksでもトップレベルとして扱われ、--no-childに一致し、--childには一致しません。ピン留めする場合は作成後に既存のtask pin <task-id>を使います。作成時の自動ピン留めは行いません。

親子関係はタスク一覧と子タスクパネルの階層を作りますが、結果配送の契約ではありません。

子タスクが停止点へ達しても、親が自動的に全成果を受け取るとは限りません。親側はtask runの返り値、task wait、またはtask getから必要なレポートを読み、差分、テスト、URLなど依頼した証拠を確認します。

タスクメニューから子タスクを削除する

DesktopとPWAでは、子タスクを持つタスクのメニューから子タスクを一括削除できます。確認すると、さらに下の階層にある子タスクも含めて削除し、親タスクは残します。キャンセルすると削除しません。実行前に子タスクの階層全体を確認してください。

状態と待機理由を読む

cockpit task list
cockpit task list --status waiting_confirmation
cockpit task list --parent <task-id>
cockpit task list --parent <task-id> --recursive --all
cockpit task list --summary
cockpit task get <task-id> --turns 3 --max-lines 500

--parentは指定した親自身と直接の子を、--recursiveを加えるとすべての子孫を返します。完了済みは既定で除外されるため、含める場合は--all、完了済みだけなら--status completedを指定します。--directoryと--nameでさらに絞り込めます。絞り込みで親が非表示でも、再帰探索はその階層を通過します。存在しない親はtask_not_found、--parentのない--recursiveは入力エラーです。

親指定の一覧は常に軽量summaryです。通常の一覧も--summaryで同じ形式になり、id、name、status、stopReason、hasPendingAsk、parentMasterId、directory、projectId、agentType、作成・更新時刻だけを返します。どのプロジェクトにも属さない場合、projectIdはnullです。応答全体のgeneratedAtでsnapshot時刻を確認できます。指示、会話、report、model設定、device情報は含まれないため、詳細が必要なタスクだけtask getで読みます。

waitingReasonがpermissionまたはquestionなら、エージェント内の確認が続いています。readyForNextPromptがfalseの間に別の指示を重ねません。usage_limitなら利用できるアカウントとリセット時刻を確認します。

通常・summaryのtask list、task get、task waitのタスクsnapshotは、共通のstopReasonを返します。値はapproval、turn_ended、usage_limit、question、terminal_prompt、runtime_error、unknownです。実行中・完了後はnullです。turn_endedはタスク全体の完了ではなく、1ターンの終了を示します。確かな記録がなければunknownになり、セッションIDだけでは終了と判断しません。hasPendingAskは承認要求とは独立しています。

起動に失敗したタスクを再試行する

startFailed: trueのタスクは、新しいタスクを作らずretry-startで起動をやり直せます。既定では保存された最初の指示またはTerminalコマンドを再利用します。入力を置き換える場合だけ、新しい本文を渡します。

cockpit task retry-start <task-id>
cockpit task retry-start <task-id> --instruction-file retry.md
cockpit task retry-start <task-id> --directory /path/to/folder

--directoryは、まだセッションを開始していない単独タスクだけで、再試行前に既存の作業フォルダへ変更します。子タスク、Master Agent、分岐タスク、Worktree、Creative Studio、既存セッションでは利用できません。存在しないフォルダは自動作成せず、変更したタスクは新しいフォルダを含むプロジェクトへ割り当て直します。保存済みの指示と添付は維持します。

retry-startは起動失敗専用です。停止済みのタスクにはresume、既存のビジュアルセッションへ再接続する場合はreconnectを使います。完了済み、実行中、または起動失敗以外のタスクは再試行できません。

保留中の承認と質問に応答する

task getのturnRequestsには、実行環境が現在保持しているツール承認と構造化質問だけが表示されます。判断前にrequestId、kind、requestType、操作内容を示すdetailを確認します。質問にはID、選択肢、複数選択と自由入力の可否も含まれます。

cockpit task get <task-id>
cockpit task approve <task-id>
cockpit task approve <task-id> --scope always
cockpit task deny <task-id>
cockpit task answer <task-id> --text "選択肢A"

approveの既定は今回だけの許可です。--scope alwaysは同種の判断を記憶するため、範囲を理解した場合だけ使います。複数のリクエストがある場合は--request <request-id>で対象を固定できます。denyは範囲や理由を受け取らないため、拒否理由も伝える場合は拒否後にtask sendで説明します。

複数質問には質問順に--textを一つずつ渡します。質問IDを固定する場合や複数選択には、質問ごとに--question <question-id>と一つ以上の--choiceを使います。回答数、質問ID、単一・複数選択、選択肢は送信前に検証されます。

cockpit task answer <task-id> --text "はい" --text "ステージング"
cockpit task answer <task-id> \
  --question checks --choice lint --choice tests \
  --question deploy --choice staging

task answerは実行中エージェント自身の質問へ回答します。人へ判断を委ねるCockpit Askへ代理回答するcockpit ask answerとは別の操作です。

レポートを順番に受け取る

task runとtask waitが返すreport.seqはタスクごとに増加します。処理済みの番号を--sinceへ渡すと、同じレポートを重複処理せず次のレポートを待てます。

cockpit task wait <task-id> --since <last-seq> --timeout 110

timeout: trueはタスク失敗ではありません。現在状態を必要に応じて確認し、同じ--sinceから待機を続けます。短い間隔でtask getを繰り返す代わりに、継続監視にはtask waitを使います。

子タスクの承認待ち開始と解除も、approvalEvent: approval_waitingまたはapproval_resolvedのレポートを追加し、親タスクの永続キューへ通知します。親が実行中なら次の入力が可能になったときに届け、完了済み・存在しない親は再開しません。同じ状態の再保存では重複通知しません。通常の成果レポートは引き続き親が取得します。

approval_resolvedは待機の解除を示し、承認された、成功した、という意味ではありません。中断、エラー、利用上限、完了による解除も含みます。複数の承認要求があれば最後の1件が解消するまで承認待ちが続きます。通知は要求を自動承認せず、権限やモデル、親のエージェント切替予約も変更しません。

approvalEventを受け取ったら成果として扱わず、そのseqを指定したtask wait --since <seq>で待機を続けます。エラー・完了へ移る際の解除通知は直前の非終端状態を保持し、実際のエラー・完了内容は通常レポートが返します。現在の状態はtask getで確認します。Fleetは承認通知を自動で読み飛ばして成果を待ち続けます。

追加指示を送る

タスクが次の指示を受け取れる状態ならtask sendを使います。そのターンのレポートまで必要な場合は--waitを付けます。

cockpit task send <task-id> --text "失敗したテストだけ修正し、再実行してください" \
  --media ./failure.png \
  --wait

複数行の指示は--stdinまたは--text-fileで渡します。task sendの--mediaにも作成時と同じ件数、サイズ、ローカルファイル、エージェント対応範囲が適用されます。確認画面に対してEnterを送るだけなら、本文を付けずcockpit task send <task-id>を実行します。送信前にwaitingReasonを読み、質問への回答なのか、ツール許可なのか、通常の追加指示なのかを区別してください。

ターンと会話をCLIから管理する

cockpit task cancel <task-id>
cockpit task compact <task-id>
cockpit task clear <task-id> --confirm
cockpit task approval-mode <task-id>
cockpit task approval-mode <task-id> accept-edits

cancelは実行中のターンだけを停止し、タスクと会話を残します。compactは会話を圧縮します。clearは会話と最初の指示を破棄して新しい会話を始めるため、--confirmが必須です。リセットは、そのタスクを開いているすべてのDesktopとPWAへ反映されます。実行元以外の画面では、入力途中の本文、添付、キューを保持します。

compactとclearは、実行中、ツール承認待ち、質問への回答待ちのターンではtask_turn_in_flightとして拒否されます。ターンを完了するか、保留中の確認へ応答するか、先にcancelを実行してください。approval-modeはモードを省略すると現在値を読み、指定するとそのタスクだけを変更します。Cockpit Agentの実行中セッションを作成時より厳しいモードへ変えた場合は、完全な適用に新しい会話または新しいタスクが必要で、CLIの結果にwarningが返ります。

対応範囲はエージェントとUIモードで異なります。

• Claude Code、Codex、Grok BuildのネイティブUI: すべてのターン管理コマンド
• Cursor、QoderのネイティブUI: answer以外
• AntigravityのネイティブUI: cancel、compact、clear、approval-mode
• Cockpit Agent: approve、deny、answer、cancel、approval-mode
• すべてのターミナルUIとTerminalタスク: 対応なし

対応しない組み合わせは終了コード1、現在の状態に合わない操作は終了コード3、Cockpitへ到達できない場合は終了コード7です。自動処理では、終了コードに加えてJSONのcodeと現在状態を確認してください。

エージェントのGoalを開始する

ビジュアル実行環境がgoalCommandAvailable: trueを返すタスクでは、CLIから新しいGoalを開始できます。これは実行エージェントへ実際のターンとして送信されます。Cockpit Agent、Terminal UI、Terminalタスク、およびGoal未対応の実行環境では使えません。

cockpit task goal start <task-id> --objective "リリース確認を完了する"
cockpit task goal start <task-id> --objective-file goal.md

CLIはGoalの停止や消去には対応しません。開始後はtask get、task wait、通常のターン操作で状態を監督します。

アカウントとBrowser Identityを切り替える

利用上限などで続行できない場合、対応するエージェントではタスクのアカウントを切り替えられます。切り替え後、停止理由に応じて続行指示を送ります。

cockpit task account <task-id> work

Browser Identityの変更は、そのタスクの次のブラウザーセッションへ使う永続領域を切り替えます。CookieやlocalStorageをIdentity間でコピーしません。

cockpit task browser-identity <task-id> work

完了、再開、削除を区別する

完了や削除は、利用者が明示的に求めた場合だけ行います。差分、生成物、レポート、公開URLなど必要な成果を保存し、対象IDを再確認してから実行してください。

完了を判定する

タスク管理の完了は、表示上の状態だけでなく次を確認します。

• 依頼した成果と証拠をレポートまたは実ファイルから回収した
• 確認待ち、利用上限、エラー、タイムアウトを未解決のまま残していない
• 親タスクが子タスクの結果を必要な順序で統合した
• 外部公開や削除は承認された対象だけに行われた
• 作業場所を消す前に必要な変更を保存した

全構文はcockpit task Reference、画面上の確認はタスク一覧とタスク詳細を参照してください。