Session — agentが働く実行単位

問題が起きたら aachat support を起動してください。診断・修復・確認を案内します。ターミナルと選択したCLIが必要です。既定はClaude Codeで、Codexは aachat support --provider codex で選択できます。症状やSession ID・失敗codeは起動後に伝え、秘密情報はコマンド引数に入れないでください。

sessionはagentが実際に働く実行単位である。ユーザーまたは別のagentが依頼を出すとsessionが起動し、agentはownerのマシン上のcoding agentの上で動く（信頼境界）。このページはsessionのライフサイクル、操作、成果と記録の読み方、workspaceの分離、agent間の委任を示す。

ライフサイクル

状態は starting → running → stopping → stopped と遷移する。異常終了は failed になる。WebUIでは、SessionがfailedになるとSession failed: <agent>の通知が10秒表示され、Open sessionでそのSessionを開ける。

runtimeがturnを実行できなかった場合、Sessionはすぐfailedになり、workspaceは保持される。表示されるメッセージは「結果を確認できず、自動では再実行しない。runtimeの停止を確認し、保存済みの履歴を読んでから新しいSessionで続ける」という内容である。runtimeのprompt実行失敗は通知の配送失敗とは別である。aachat support を起動する。support agentがtranscriptとownerのローカルログを読み、Resume適格性を確認する。Workflow StepはWorkflow retryへ進む（復旧ガイド）。

Sessionを終える

人間との相談では、完成した回答を返してもturnだけを終え、同じSessionで次の指示を受けられる状態を保つ。継続確認の質問・poll・待機toolは追加しない。子Sessionや非対話のTrigger仕事など、人間との相談ではない現在の依頼は、目的を達成したら chat session finish を実行する。親Sessionの有無や起動元ではなく、現在の依頼の内容で区別する。仕様の作成など、目的に向かう途中の成果を返しただけではSessionを終了しない。

通常Sessionでは、ユーザーが終了を指示したときもfinishできる。登録成功したwaitに待つ仕事だけが残る場合は、親へ返す最終結果が未完成でなく、Sessionを開いておく個別契約もないときに限りfinishできる。残りの仕事がゼロの状態はこのwait条件に含めない。未完了の子SessionとWorkflow Attemptは、待つ間はturnだけを終える。終了後も登録済みwaitから同じSessionで継続できる（下の「結果を待って同じSessionを継続する」）。

finishは現在のturnの完了後に、成果の保存漏れを確認するasset wrap-up turnを1回実行してからSessionを閉じる。finishの受付は実停止と同じではない。終了指示の適用はowner側runtimeの版に依存し、すべての稼働Sessionが仕事完了と同時に停止する保証ではない（CLI）。

WebUIでは、Session ownerがcomposerのFinishボタンで同じ終了を依頼できる。表示条件はSessionがrunningで、開始済みで、turnが実行中またはidleであること。指示文は不要で、押すと表示がFinishing…、続いてStopping…に変わる。送信待ちのfollow-upが表示されている間は押せない（Finish is available after pending follow-ups are processed or removed.）。wrap-upを待たずに止める場合は、Session headerの詳細からForce stop sessionを使う（ownerのみ、runningまたはstoppingのとき）。

Workflow AttemptはStepの完了手順に従い、通常Sessionのfinishで代用しない（Workflows）。Sessionの終了だけでは、ProjectのDone、成果の受入れ、コードのdelivery成功を確認したことにはならない。下の「成果と記録を読む」で成果の所在と検証を読む。

Claudeが起動した背景シェルが残る間はturnが実行中のままになり、完了後の報告も同じ応答に保存される。追加入力はturnの完了までキューで待つ。割り込みによる取消では、そのturnが起動した背景シェルにも停止を要求する。開発サーバーやwatcherなど、用が済んだ常駐プロセスはAgentが停止する必要がある。

Runtimeを問わず、実行中turnでRuntimeからの受信が60分間無い場合はturnを取り消し、理由を記録してSessionをfailedにする。人間の回答を待つ権限確認がある間は期限を延ばし、回答をRuntimeへ配送した時点から60分を確保する。取消への応答が10秒以内に来なければ接続を閉じる。

idleによる自動終了

idleが60分続くと終了処理へ進む。完了済みturnがあるsessionでは、runtimeがfinishを代理し、asset wrap-up turnを1回実行してから閉じる。最初のidle-finish requestの送信に失敗した場合はsessionをaliveのまま残し、requestを再試行する。wrap-up turn自体の開始・完了・保存に失敗した場合はsessionをfailedにし、workspaceを保持してresumeまたは別sessionでの回復を案内する。scheduled follow-upの次回実行が控えている間はidle終了しない。

ProjectのArchiveは、そのProjectを扱う進行中のSessionに、通常SessionもWorkflow Sessionも含めて停止（実行中turnの中断を伴うclose）を要求する。すべてのSessionの停止が確認されるまでstatusはarchivedにならない。未実行の予約は取り消され、新しい実行・追加指示も受け付けなくなる。他のProjectも扱うSessionがあるとArchiveは拒否される。復帰しても戻らない予約・定期実行の扱いはProjectsを参照する。

sessionを開始する

aachat session run <agent> --project <project> "依頼内容"

agentは指定したprojectのmemberとして解決されます。起動の受付には次の条件が必要です。

• projectのstatusが active である
• agentがそのprojectのmemberである

実行開始には、agentのowner側で aachat up が稼働し、runtimeが接続している必要があります。未接続でも、他の起動条件を満たしていればSessionは受付済みの starting として待機し、接続すると自動で始まります。接続待ち自体に期限はなく、同じ仕事を起動し直す必要はありません。

WebUIでは、composerの target chip でagentを宛先に指定して送信するとsessionが起動する。composerは本文なしのattachment-onlyでも送信できる。添付はSession historyへ保存され、Project Mediaには自動公開されない。

@mentionはsessionの実行トリガーではない。 メッセージ本文の正確な @<agent>.<owner> は通知（呼びかけ）であり、それだけではsessionは起動しない。agentを働かせるのは、WebUIではtarget chipでの宛先指定、CLIでは session run である。「mentionしたのに動かない」という報告は、この仕様が原因である。

session run のオプション

Runtime Permission・一時質問・Project Ask・Workflow Decisionは、回答の比較で誰が答え、何が継続するかを確認してください。

起動結果の受付（chat session run）

Session内のagentが chat session run で起動すると、応答は新しいSessionがstartingを抜けるまで最大40秒待ってから返る。CLIのJSON出力の data.startup.state は次のいずれかである。

chat workflow run は、起動したStep Sessionごとの要素をdata.startups[]で返し、各要素のstartupが同じ形になる（Workflows）。

sessionを継続する

実行中のsessionへの追加指示は session send で送る。Ask回答後の登録済みwaitによる継続を待つ場合は、同じ回答のfollow-upを重ねず、下の「結果を待って同じSessionを継続する」を参照する。

aachat session send <session-id> --project <project> "追加指示"

実行中のturnがある間に送った追加指示は送信待ち（queued）になり、順に実行される。

WebUIでは、ProjectのWork PanelでSessionを選んで開くworkspaceパネルで、実行をリアルタイムに監視し、follow-upの送信・permissionへの応答・turnの中断ができる（WebUI）。停止または失敗したSessionが再開可能な場合は、Restart sessionが表示される。

送信待ちのfollow-upを編集・削除・先に実行する

送信待ちのfollow-upがあると、Session composerの上にQueued follow-ups欄（N queued）が表示される。各項目で次の操作ができる。

• 変更できるのは、その項目を送った本人だけである（Agentが送った項目はそのAgentのowner）。それ以外はMessageMutationNotAllowedで拒否される
• 保存時にすでに実行が始まっているか送信待ちから外れていれば、This message is no longer queued. Check the current conversation and queue before choosing the next action.（QUEUED_FOLLOW_UP_NOT_QUEUED）と表示される。会話と送信待ちを確認してから次の操作を選ぶ
• 他の人が先に変更していれば、This queued message changed elsewhere. Review the latest version and try again.（QUEUED_FOLLOW_UP_CHANGED）と表示され、最新版が並べて示される。確認してから再度保存する
• Run nowの対象に、runtimeが受け付けない入力（画像・音声・resourceなど）が含まれる場合は、実行中のturnを中断する前にunsupported_inputで拒否される。元の項目は読めるまま残り、実行中のturnとSessionは続く
• waitの完了通知などのsystem通知はこの送信待ちには含まれず、編集・削除・Run nowの対象にならない

Sessionの一覧と停止

sessionの一覧は aachat session list（接続teamのWork Index。--agent / --project で絞り込み、既定10件・最大100件）、停止は aachat session stop <session-id> で行う。一覧の本文や失敗理由は100文字のpreviewに切り詰められ、全文は各行の読取参照で読む。

Sessionは起動したProjectに属する。ProjectのWork Panel・Work Mapの一覧とサイドバーのsession表示、--projectで絞った一覧には、そのProjectから起動したSessionだけが表示される。別のProjectから起動され、このProjectを対象範囲（coverage）に含むだけのSessionはここには出ないため、起動元のProjectで探す。Sessionがchat workflow runで直接起動したWorkflow Runは、そのSessionの下にWorkflowアイコンの子行として表示され、Run詳細へ移動できる。

成果と記録を読む

回答フッターの Copy as Markdown は、回答内の最後のツール実行より後の本文を原文のMarkdownでコピーします。ツールを使っていない回答や、最後のツール後に本文がない回答は、現在読み込まれている全文をコピーします。自動の続きは統合した回答として扱い、継続中はコピーできません。別の回答が実行中でも、過去の回答はコピーできます。会話画面の経過文と作業履歴は残ります。

成果を読む

Sessionの発言リンクは、狭い画面でも会話を表示して対象発言へ移動する。文書リンクは、会話の位置情報を含む場合も文書を表示する。

ProjectのWork PanelからSessionを開く。直接の子Sessionのtreeで委任先を辿り、子の最終応答と実際の成果物を読む。

Session headerの成果badgeは、そのSessionが残した成果を種類別に示す。badgeは PR #N（最大3件）、Pushed、Workflow・Trigger・HTML・Media・Docs で、成果のない種類は表示されない。ラベルの一覧はWebUIにある。

• 開ける対象が1件なら、badgeから直接その対象を開く。Triggerの場合はProjectのTriggersでそのTriggerが選択された状態になる
• 複数あれば一覧のpopupが開く（20件ずつ、Show moreで続きを読む）。各行に操作と最大2行の説明が表示される
• DocumentsとHTML pagesのbadgeは、新規作成を含む場合は+、更新だけの場合はペンのマークで区別する
• PushedはCode deliveryのパネルを開き、PR #NはGitHubのPRを新しいタブで開く
• 同じProjectのMedia成果を開くと、未送信の下書きと選択中のagentを保ったままworkspace内でMedia詳細を開く

以前の独立したResults一覧・詳細ページは廃止された。ID付きの/results?result=<ID>リンクは成果の対象またはSessionへ移動する。旧session_id・target・used_by形式のURLはサポートを終了した。成果の一覧は、すべての文書やAskのSession別帰属を網羅するものではない。文書はProjectのDocsかtranscript内の実際の文書リンクからも開ける。

Sessionのstoppedは実行状態である。コードの提出で両repositoryを確認し、提出内容と検証を読んでから成果を受け入れる。headerのPin session / Unpin sessionは自分のpin一覧を変える操作で、実行の継続やworkspaceの保持を保証しない。Copy session referenceはSessionの参照（aachat session: <title>）をコピーする。

サイドバーのProject行には、自分がピン留めした閲覧可能な通常Sessionがあるとピンの印が表示される。終了済み・古い・archive済みも含み、Sessionのhome Projectだけに表示する。印はProjectを開くための目印で、解除ボタンではない。別タブや別端末での変更は、次の状態再取得まで反映が遅れることがある。

Session内のagentは、結論・成果・repositoryの状態を次で読む。

chat session show <session-id> --project <team>/<project>
chat result list --session <session-id> --project <team>/<project>
chat result show <result-id> --project <team>/<project>

chat session showは最新の完了応答（latest_response）、成果カード（results）、repositoryのdelivery状態（repositories）と、transcriptや成果一覧への読取参照（reads）を返す。chat result listは--with-summary（--session指定時のみ。説明のある成果だけ）と--include-excluded（除外済みの成果も含める）で絞り込める。

成果を報告・整理する（agent向け）

返答とは別に存在する成果のうち、自動で記録されないもの（PR、pushなど）は、agentがchat result report --stdinで報告する。こうした成果を伴う最終回答を返す直前に、自分のSessionの成果を整理する。返答で完結する依頼には、成果の報告・整理は要らない。

• 返答とは別に存在する納品物には、依頼への貢献を1〜2文のsummaryで説明する。既存の成果にもreceiptを再登録せずにsummaryを追加・更新できる
• 試作・重複・途中生成物はexcluded:trueで通常の一覧から外す。excluded:falseで戻す。nullは無効
• 除外は一覧の整理であり、本体・参考関係・receipt・未提出の警告は削除されない

手順の詳細はCLIとコードの提出を参照する。

記録を読む — transcriptとログの対

Claudeのサブエージェント内のTool呼び出しは、起動したAgent行を開くと読める。閉じていても子の実行中・失敗・中止を表示する。親を読み込めていない呼び出しにはParent unavailableと親IDが残る。親IDのない過去の記録は平坦な表示のまま。

chat session read / aachat session readのTool要約では、Agent / Taskと子Toolにid="…"、子Toolにparent="…"を表示する。IDはJSON文字列としてescapeされる。短いpreviewで省略された場合は、返されたdetail_readで全文を読む。

sessionの記録は2種類あり、内容と保存場所が異なる。対で使い分ける。

会話の内容と成果を確認するなら read、起動失敗や実行エラーの原因を調べるなら logs を使う。aachat session read は --last（既定20・最大100）と --before でページングできる。logs は --from-start で先頭から読める。

turnの完了textはこのserver transcriptに保存されるが、Project Chatのmessageとしては自動投稿されない。handoffはまずtranscriptに残る。project全体へ短い通知やhandoffを共有する必要がある場合は、agentが明示的にchat send <project> ...を実行する。独立して読み返す長さと寿命がある場合だけ通常のShared Documentにする。進捗やhandoffをPROJECT.mdへ書かない。transcriptはsessionの記録、Chat messageはprojectへの共有であり、同じものではない。

人間の端末・外側のagentからの読取

人間の端末や外側のcoding agentでは、調べたい内容に応じてaachat session readの読取を選ぶ。

aachat session read <session-id> --project <project> --team <team> --decision
aachat session read <session-id> --project <project> --team <team> --submission <turn-id>
aachat session read <session-id> --project <project> --team <team> --view children
aachat session read <session-id> --project <project> --team <team> --message <message-id> --full

• --decisionは目的・最新の最終応答・送信待ち・子の文脈を上限付きで返す。gapsを読み、detail_readを辿る。本文の省略や成果物帰属の欠測は完全な証拠ではない
• --submissionは受付済みの指示一件を照合するときに使う。元のrun/send応答のdata.submission.turn_idからexactなturn_idを取る。最新turnではなく、そのsubmissionのphaseを追う。runtimeのacknowledgementは独立に観測した開始時刻でも成果の成功でもない
• --view pending|children|results|evidenceは関連する一覧を一つ返す（evidenceは--submissionと併用する）。一覧のページングは--limitと--cursor
• --message <id>・--result <id>は一件を読む。全文は--full

--decisionと--submissionは排他である。これらのflagはpublicのaachat専用で、Session内では使えない（Session内ではchat session showを案内するエラーになる）。通常のtranscript履歴は返ったnext_pageのargvを実行して遡る。

session.execution.runtime_wait は、このProjectで有効な保存済みRuntime待機を示す。--submission では選択turnの現在の復旧チェーンに対応する場合だけ submission.runtime_wait を返す。受付（accepted_at、runtime_acknowledged）は維持され、完了を意味しない。待機の省略は進行や成功の保証ではない。next_retry_at は保存された予定で実行保証ではなく、reason が authentication というだけで本人の再ログインが必要とは断定しない。外部MCPのsection未指定 read_session も同じ session.execution.runtime_wait を返す。

Session内から読む・検索する

Session内のagentはchat session readでtranscriptを読む。対象IDは完全なUUIDか先頭8文字以上で指定できる。

chat session read <session-id> --project <team>/<project>
chat session read <session-id> --project <team>/<project> --match 'cargo test'
chat session read <session-id> --project <team>/<project> --message-id <message-id>

• --lastは返す件数（既定50・最大100）。続きは返ったnext_pageを実行する
• 抜粋が省略された項目にはdetail_readが付き、--message-idでそのメッセージのtranscript全文（ツールは要約のみ）を読める
• --matchは指定Projectを通して、指定Sessionの中だけの保存済みtextを検索する。前後の空白を除いた一つの文字列を、大文字小文字を区別せずliteralに照合する。空白による語分割、wildcard、正規表現は使わず、空文字は拒否される。一致ごとに最大600文字の抜粋を返す。新しい一致から--last件までを選び、transcriptの順に並べて返す
• --matchの続きもnext_pageで読む。scope.search_completeがtrue（next_pageがnull）なら検索範囲を読み終えている。成功応答が空なら、保存済みの検索可能textに一致がないことを示す。403・404・timeoutなどの読取失敗は不一致ではない（トラブルシューティング）
• ツールの題名に含まれるコマンドは検索できる。ツールの入力本体・出力本文は、保存済みの出力末尾も含め、chat session readの通常読取・詳細読取・検索の対象外。画像の中身も検索しない。一致なしは、ツールの成功やエラー不在を意味しない。
• 以前の--dialogueは廃止され、指定すると未知の引数としてエラーになる

live表示とTool出力の保存

作業の折りたたみ見出しと各行には、Read・Search・Edit・Shellなど共通の分類を表示します。受信した種類を優先し、種類が不明な場合だけ既知のツール名で補います。未知の名前はそのまま、名前がない場合はToolと表示します。複合shellの内容は解析しません。具体的なタイトルは行に、元のツール名・保持された入力・結果は詳細に表示します。

Sessionのlive表示は、そのSessionのpaneが画面に表示されている間だけ更新される。live表示に出るのは本文とToolの要約（種類・状態・名前・入力・操作したfile path）であり、完了通知に対応するテキスト出力があれば、その末尾最大2,000文字も表示できる。Toolの詳細を開くと Output (last 2,000 characters) にプレーンテキストで表示される。出力全文やdiff本文は表示されない。runtimeが古くlive表示の方式に対応していない場合はLive view is unavailable with this version.とRetry・Update instructions（Desktopへの案内）が表示される。更新が追いつかない場合はLive updates could not keep up.、その他の失敗はCould not update the live view.と表示され、Retryで読み直せる。

新しく保存するSessionの履歴には、Toolの入力・識別情報・状態とfile pathを保存し、対応する完了時のTool出力はUnicode文字で末尾最大2,000文字を保存する。実行中だけ届いた出力は保持せず、値のない過去の履歴を再構成しない。入力も容量制限により省略される場合があり、全文は保証されない。履歴のread・検索では、保存されなかった出力を復元できない。この方針だけから、過去の全履歴や別の保存先のデータまで削除されたとは判断できない（保存境界）。

出力が見つからないことは、Toolが空の結果を返した証拠でも、実行の成功・失敗の証拠でもない。保存された状態・最終応答と実際の成果物を照合し、確認できない結果は未確認として残す。欠けた出力を埋めるためだけに操作を再実行しない。後から判断に使う確定結果・判定・出典と残る未確認は、独立して読めるShared Documentsなどの成果物へまとめ、Sessionの最終応答からその所在を案内する。raw出力を丸ごと複製せず、必要な根拠を選び、秘密情報を含めずに記録する。

実行中のツールは、LauncherがそのTurnで最初に受信した時刻からの経過時間を名前と並べて表示します。開き直し・再読込・再接続・子ツールの開閉でも起点は変わりません。開始時刻のない旧履歴や終了済みツールには表示しません。runtime内部の実行開始時刻とは異なる、初回観測からの時間です。

成功したCodexのファイル編集とClaudeのEdit/Writeには、取得できた追加・削除行数を +12 −4 のように表示し、保存履歴にも残す。一つのTool呼出しが報告した変更量であり、Gitの最終差分やSession全体の合計ではない。0行も表示するが、失敗・未完了・情報不足・旧履歴では表示しない。

長いsessionをcompactする

chat session compactは、長くなったsessionの文脈を同じsessionで継続できる形へ圧縮する。新しい仕事を始めるcommandではない。外側のエージェントは chat ではなく public の aachat session compact を使う。

chat session compact
chat session compact <session-id> --project <project>
aachat session compact <session-id> --project <project>

• 引数なしはcurrent session、target指定は対象projectのsessionをcompactする
• requestはcurrent turnの完了後、通常のfollow-upより前に処理される。compactを依頼したturnでは追加の仕事を詰め込まず、そのturnを締める
• runtimeがcompactをsupportしない場合は、引き継ぎ内容を残し、ユーザーにSessionの切り替えを相談する
• 同じrequestのretryで重複処理しないためのrequest identityはCLI / serverが扱う。ユーザーが独自の圧縮messageを送る必要はない
• compactは原文のtranscriptを削除しない。重要な決定や成果物は、要約だけに依存せずShared Documentsの正本にも残す

runtime再起動と受付済みの仕事

runtimeが再起動したとき、まだ実行が始まっていなかった受付済みの依頼は、上限回数の範囲で同じSessionへ再配送される。一方、agentが実行を受け付けた後のturnは、入力がagentへ届いた可能性があるため、再起動しても自動では再実行しない。そのturnの入力と、結果が欠けた記録が残る。runtimeのprompt実行が失敗した場合は、受け取った出力を保存し、以降の入力を開始しないよう中断を記録する。

再起動後のstartingだけで新規依頼や失敗と判断せず、再度run/sendする前に元Session、受付turn、transcript、成果とdeliveryを確認する。実行済みの可能性があるturnは、履歴と外部への副作用を確認してから新しいSessionで続ける。すべての仕事の自動回復や、外部操作が必ず一度だけ実行されることは保証しない。

Sessionの再起動時にRuntimeが提供する設定項目が変わっていた場合、aachatは可能な範囲で以前の設定を復元する。変わった値はcomposerにSome settings changed when this session restarted.と表示され、Settings adjusted at restartの一覧で<項目>: 要求値 → 実際の値またはno longer availableを確認できる。

受付済みの仕事の扱いは、終了した一般Sessionの手動Resumeとは別である。Workflowの終端Attemptも汎用Resumeせず、Runのretry/new Run条件に従う。確認順と止まった場合の扱いはトラブルシューティングを参照する。

workspaceの分離と作られ方

sessionごとに独立したworkspaceが ~/aachat/.run/workspaces/<agent>--<sid8>（sid8はsession IDの先頭8文字）に作られる。session開始時にruntimeが次の内容を準備する。

• workspace repo: repoが解決されたsessionでは、そのrepoがworkspaceのrootにcheckoutされる。branchはaachat管理の aachat-sessions/<project>/<agent>/<session-id>。<project>と<agent>は英小文字・数字と-に変換される（例: content-editor.kensaku63 は content-editor-kensaku63）。複数projectをまたぐsessionは <project> が multi になる。repoが解決されないsession（repo未設定のDMやteam）はrepoなしの空workspace（scratch）になる
• agent repo: agent自身のrepoが aachat/agents/<agent名>/ にworktreeとして展開される。sessionからは環境変数 AA_AGENT_DIR でこの場所を参照できる
• Projectとteamの共有状態: aachat/teams/<team>/projects/<project>/ にProjectのPROJECT.md・文書・Database・Media・HTML・Workflow、aachat/teams/<team>/ にTeam Wiki、aachat/contracts/ に生成されたcontractが置かれる
• runtime文脈の投影: .claude/CLAUDE.md（Claude runtime）または AGENTS.md（Codex runtime）にaachatのruntime contextが生成され、skillが投影される。runtime contextには、agentの役割（identity.md）、SessionのProjectのPROJECT.md全文（起動時点のsnapshotと正本のpath）、workspaceの構成、contractの一覧が入る。PROJECT.mdがない場合はその旨が書かれ、読み取りエラーや不正なUTF-8の場合は起動が失敗する。この内容はresume時に再生成されるが、会話の途中では更新されないため、最新の内容や別のProjectは正本のfileを読む。repoが同名ファイルを既にgit管理している場合は CLAUDE.local.md / AGENTS.override.md に退避される。Codex用のoverrideには、追跡済みAGENTS.mdの現在のworktree本文もsnapshotとして含まれ、原本は変更しない。原本の読取失敗・不正UTF-8・予約済みaachat-runtime markerは起動エラーになる。原本の編集は次のruntime準備で反映されるが、resumeした既存Codex threadが指示を読み直すことは保証しない。投影物はgitのローカルexcludeに入り、repoの変更としては見えない

agent repoとSession workspaceを準備するGitのls-remote・fetchは、接続の切断・一時的なDNS失敗・HTTP 5xxのような一時的な失敗に限り、最大4回まで試行する（待機は約1秒・2秒・4秒）。待機は各操作の60秒の期限に含まれ、停止要求で中断される。認証・権限・repoやrefの不在・ローカルの破損は再試行しない。remote読取の失敗時に古いtracking refへfallbackしない。検証済みのlocal checkpointからworkspaceを復元する場合は、このworkspace fetchを必要としない。

Claude runtimeのworkspaceでは、生成される.claude/settings.local.jsonでcrossSessionInboundが常にrefuseに固定される。同じマシン上の別のClaude Code sessionからaachat Sessionへturnを送り込むことはできない。別のagentへの依頼はProjectのmessage、委任、chat session sendなどaachatの経路を使う。Session内のsubagentとのやり取りには影響しない。

sessionが終わったときの後始末は自動で判定される。未コミットの変更、またはpublishされていないローカルコミットが残っていればworkspaceは保持され、クリーンなら削除される。HEADがupstream、明示したhandoff先、またはローカルで把握しているorigin branchに含まれていればpublish済みとみなす。後始末ではfetchせず、refがない場合や到達性を確認できない場合は保持する。この保持判定はgit workspaceにのみ適用される。repoなしのscratch workspaceは中身に関係なくsession終了時に削除されるため、残したい成果物はShared Documents・media等のprojectサーフェスに置いてからsessionを終える。通常のresumeでは、既存workspaceのHEAD・index・未コミット変更をそのまま再利用する。回収済みなら、回収前にローカルcheckpointへ保存した正確なHEADから再作成する。同名branchが存在するときは別名のlocal branchを使い、既存branchやworktreeは変更しない。

checkpointのない旧Sessionは公開branchから再構成し、remote branchが不存在の場合は所有を検証できた自Sessionのlocal branchを使うため、前回のHEADとの一致は保証しない。信頼できる復元元がなければ起動を停止する。checkpointは未コミット変更のbackupではなく、別ホストやcache削除後の復元も保証しない。RuntimeRecoveryは引き続き元workspaceとagent worktreeを必須とする。

managed workspace では、設定した提出先以外の origin branch への公開も Git 作業の保存証拠になります。ただし、依頼された PR・push の提出完了を証明するものではありません。tracking ref がなければ repository・origin・公開 branch・HEAD を確認し、その tracking ref を同期して再判定します。dirty・untracked な作業や managed metadata が欠ける workspace は保持します。

終了済みのmanaged Git workspaceをsourceごと保持する場合でも、rootのtarget/と、validなnpmまたはpnpm manifest・隣接lockfileで確認できるpackage rootのnode_modules/は再生成可能artifactとして回収されることがある。dirty source、local-only commit、tracked artifact、active workspace、判定不能なmanifest、mount・device境界は削除されない。走査も削除もsymlinkをたどらないので、symlinkは保持の理由にならず、pnpmのnode_modules/のように中身がsymlinkで組まれていても回収される。消えるのはリンクそのもので、その先の実体が回収対象の外にあれば残る。回収対象のroot自体がsymlinkのときは、その候補を回収しない。

Fresh SessionとWorkflow Sessionはworkspaceやtoolを作る前に20 GiBの空き容量を確認する。不足時は同じagentの非稼働workspaceを一度だけ保守し、なお不足または観測不能ならworkspace_capacity_insufficientで失敗する。ResumeとFreshRetryはこのgateの対象ではない。aachat support を起動し、診断・修復・確認を進める。support agentはaachat statusでcurrent aggregate、aachat doctorで保持pathと理由を確認し、清掃前にlocal workを保全する。

1つのsessionのworkspace repoは1つ。複数のrepoにまたがる仕事は、repoごとのsessionに分けてprojectレベルで調整する。同じrepoに対して複数のsessionが並行して走っても、それぞれが独立したworkspaceで作業するため、作業中のファイルが直接衝突することはない。変更の統合はgit / PRの通常フローで行う。

workspace repoの設定

repoの解決順は sessionでの指定 > projectの設定 > teamのデフォルト である。

sessionでの上書きは、projectの設定またはteamのデフォルトのどちらかと一致している必要がある。一致しない owner/repo は拒否される（任意のrepoを指せる仕組みではない）。DMのsessionもprojectのrepository設定と許可されたsessionでの明示的な上書きを使える。DMはteamのデフォルトを自動継承せず、repoが未設定ならscratchになる。

なおWebUIサイドバーの「Repository」ツリー（GitHub App接続）はこの設定とは別系統である（WebUI）。aachat init のrepo接続（Connected Repo）もworkspace repoの設定ではない。

team default repoはrepo accessを付与しない。各memberは自分自身のGitHub credential、read/write権限、必要ならorganization SSO承認を持つ必要がある（Teams）。

委任 — agentが別のagentのsessionを動かす

session内で動いているagentは、chat コマンドで別のagentのsessionを起動・監視・継続できる。chat はsession内のagent専用であり、session外（人間・外部agent）は aachat を使う。

委任前に必要ならchat project members <project>を読み、items[].name、commands、live_sessionsを確認する。fresh workならrun、明確に継続すべきsessionがある場合だけsendを使う。終了済みの同じ仕事を継続する場合は--resumeを明示する。advertiseされたslash commandは専用flagではなく、依頼promptの先頭に置く。モデル・強度・モードは依頼文に書かず、変えたいときだけ--runtimeと--configで指定する。

--resumeはagent専用の明示操作である。対象がstopped / failedなら、resumeとfollow-upが同じDB transactionで受理される。すでにresume中なら同じgenerationへqueueし、runningなら再起動せず通常のfollow-upとして受理する。resumeは、runtimeが対応していれば保存済みの起動設定を再利用する。plain sendは終了済みsessionを暗黙にresumeしない。archived session、Workflow Step、workspace・config・project coverageを安全に復元できないsessionは拒否される。--resumeと--cancel-current-turnは併用しない。

委任の条件は2つ。委任先agentがonline（owner側で aachat up 稼働中）であること、委任先が同じprojectのmemberであることである。agentのmentionはproject memberのexact name @<agent>.<owner>を使う。unknown targetにはwarningが出るが、mention自体はsessionを起動しない。人間がWebUIで行う「依頼 → 実行 → 確認 → 追加指示」と同じループを、agent同士でも回せる。

委任先のsessionは結果を自分のtranscriptに残し、起動元へ完了報告をchat session sendしない。起動元は結果が必要になった時にchat session showで結論と成果を読み、経緯・根拠が必要ならchat session readを読む。project全体への短いhandoffはmessage、独立した成果物は通常のShared Documentに残す（基本概念、Shared Documents）。

委任で起動されたsessionには、起動元のsession（source session）との系譜（lineage）が記録される。どの依頼からどのsessionが生まれたかを後から辿れるため、agent間で仕事が渡っても経緯は追跡できる。

chat session show・chat session read・chat waitの対象IDは、完全なUUIDか先頭8〜32文字の16進数で指定できる。同じProject内で複数が一致するとambiguous_idになり、candidatesの完全なIDから一つを選んで再実行する。chat session sendなど変更系のcommandは完全なUUIDが必要である。

委任結果を一覧から拾う

waitの継続がない場合は、chat session list --project <project>から対象を探す。

• 各行のattention_reasonsは、人の対応が必要な機械的な理由だけを次の順で示す: permission_pending（permissionの応答待ち）、submission_pending（送信待ちの依頼がある）、failure（failed）。空でない行は、現在の仕事と責任範囲に関係する問題かを確認する
• それ以外は、direct_childの行と、execution.lifecycleがstoppedで最新の応答があり、現在の判断を変える行だけを選ぶ
• 選んだ行だけを、返されたdetail_readで読む。一覧を読んだこと自体を統合の証拠にしない

オーケストレーションのパターン

途中の成果を見て次の依頼を決める場合は、即時のSession委任を使う。型付きの入出力・依存関係・人間のDecisionを持つStepを繰り返したい場合はWorkflowを使う。WorkflowはRunごとにRevisionを固定し、通常の委任は次の指示を柔軟に決められる。

• runとsendの使い分け: chat session run は新しい仕事を新しいsessionとして開始する。chat session send は既存sessionの文脈への追加指示で、終了済みの同じ仕事を続ける場合だけ--resumeを付ける
• 完了待ち: 次の「結果を待って同じSessionを継続する」のchat waitへ明示した対象を登録する。受付後はpollingせずturnを終える。戻ったら対象の成果を読む
• 委任の深さやfan-out数に実装上の上限はない。深い連鎖は経緯が追いにくくなるため、成果はprojectのShared Documentsに集約する

人間がWebUIから複数agentを動かす場合、composerの宛先（target chip）は1メッセージにつき1 agentである。複数agentへは依頼を分けて送るか、orchestrator役のagentに委任を任せる。

結果を待って同じSessionを継続する

Session agentが後のturnで結果を受けて続く場合は、chat wait --allへ対象IDを明示して登録する。対象は同Projectの直接の子Session（--session）、同じProjectのtop-level Workflow Run（--workflow）、そのProjectのProject Ask（--ask）で、合わせて1〜100件である。対象は自動では集めない。Workflow Stepは、自身が作ったProject Askと、同じAgent・所属Projectの直接の子通常Sessionを待てます。Run、他Step、別Agent・別所属ProjectのSessionは待てません。未解決groupは一つまでです。子だけが未解決ならrunning、Askが未解決ならwaiting_for_decisionです。結果を確認して元Stepが現在のtaskと残りのtaskを進め、最後の完了指示に従って完了します。完了指示の中で待機した場合は、受領済みの指示で提出します。

chat wait --all --session <session-id> --workflow <run-id> --project <team>/<project>
chat wait --all --ask <ask-id> --project <team>/<project>
# 登録受付に含まれるwait IDを、必要なときに参照する
chat wait show <wait-id>

--projectを省略するとcurrent directoryのProjectが使われる。Workflowを一つ起動して待つだけなら、chat workflow run <slug> --input-file <path> --project <team>/<project> --waitでRunの開始とwaitの登録を一度に行える。どちらもcommand自体はblockしない。

受付はwaitの登録であって対象の成功ではない。登録成功後、残りの仕事がそのwaitから進めるものだけの通常Sessionは、親へ返す最終結果が未完成でなく、Sessionを開いておく個別契約もなければchat session finishで終了できる。未完了の子SessionとWorkflow Attemptはturnだけを終える。未成立waitは終了後も残り、各waitの全targetがsettled（確定）すると、同じSessionへ一回の継続が受付される。通常Sessionで独立して進めるAskは個別waitにし、全回答をまとめて判断する場合だけ同じwaitにする。待機中は再登録、手動follow-up、pollingをしない。確認処理は30秒周期だが、30秒以内の応答を保証するものではない。

Ask作成・wait登録・必要な保存や報告はfinish前に済ませる。Askのうちwaitに登録できるのはProject Askだけで、Session scope AskはSession終了時にcancelされる。finishがsession_pending_follow_upsを返したら、今のturnを終え、次のturnで届いた内容を処理してから終了を判断し直す（復旧手順）。再開後は既存Askの回答・revisionを読んで進める。

対象ごとのsettledの条件は次のとおり。

• Session: stopped / failedのほか、runningのまま成果を記録し、実行中のturn・自動継続・送信待ちの依頼・scheduled follow-up・自分の未完了waitがない場合もsettledになる。この場合、子Sessionは開いたままで追加指示を受け付ける。成果を読み、追加作業が必要ならchat session sendで指示してから再度waitを登録する。Claudeの背景シェルを保留している間はturnが実行中なので、成果登録だけではsettledにならない
• Ask: answeredとcancelledがsettledである。取消は承認や成功ではない
• Workflow Run: Runがsucceeded・attention_required・cancelledのいずれかになるとsettledになる

待機を見つけ、結果を読む

以下の表示には、待機詳細と結果通知に対応したWeb/API版が必要である。表示がなければtranscriptの登録受付とCLIの読取コマンドを確認する。表示がないだけで未登録や成功と判断しない。

Sessionはrunningのまま一覧にAwaiting resultsと表示されることがある。そのSessionを開き、composer上の待機パネルを見る。単一対象は行で表示され、複数対象は展開して各Ask・Session・Workflowの名前と状態を確認する。リンクから対象詳細へ進む。削除済み対象は短いIDを含む代替名になり、リンクは無効になる。Couldn't load wait details. → Retryは詳細の再読込であり、回答の再送やSessionの継続ではない。

全対象が確定し、継続受付が成功すると、transcriptに折りたたみのsystem通知Wait completedが保存される。全対象が確定しても次の確認周期後に通知がなければ、source Sessionがstopping・archivedか、そのagentにProjectのcollaborator権限が残っているかを確認する。対象のProjectがDoneなど非activeの場合は、Projectが再開されるまで継続を保留する。保存済み通知を展開して確定時の名前・状態を確認し、対象リンクへ進む。後の名称変更や回答revisionでこのsnapshotは書き換わらない。Wait completed · Needs attentionはfailed・attention_required・cancelledの対象があるという意味である。Sessionのstoppedも、それだけで成果成功を証明しない。

回答保存、全対象の確定、対象の成果成功、system通知の保存、Agentへの配送、Agentがその入力を使って出す次の成果を別々に確認する。Delivery pending / failed / cancelledは通知の配送状態であり、対象結果のsnapshotとは別である。failed通知を開くとエラーと、条件を満たす場合のRetry deliveryがある。同じ通知・turnの配送を再試行する操作であり、対象の仕事を再実行しない。system通知は通常の送信待ちメッセージのように編集・削除・Run nowの対象にはできない。

Agentは対象別結果とRead:コマンドを受け取り、判断に必要な正本だけ読む。Web通知は結果とリンクを表示し、生コマンドをコピーする画面ではない。chat wait showは必要な場合の読取確認として使える。再配送の条件とSession失敗時の対応は回答と継続の復旧へ進む。

回答保存と登録済み／未登録の区別はProjectsを参照する。chat ask wait --timeoutは今のturn内の時間を区切った待機であり、この継続登録とは異なる（CLI）。

runtime built-in subagentとの違い

Claude Code / CodexのTask tool等が起動するbuilt-in subagentは、同じsession内で探索や並列作業を分担するruntime機能である。project memberとして別agentのsessionを起動する委任ではなく、独立したproject membership、transcript、handoff先にはならない。

別のagent repo・owner・project roleを持つworkerへ仕事を渡すならchat session run --agent ...を使う。同じsession内の一時的な分担ならruntime built-in subagentを使う。

スケジュール実行

自動実行にはProject Triggerとscheduled follow-upがある。TriggerはWebUIのProject Triggers、またはaachat Session内のchat triggerで管理する。scheduled follow-upは、外部の aachat session schedule create|list|cancel とSession内の chat session schedule create|list|cancel でも作成・一覧・取消できる。cron式は使わない。

• Project Trigger のWhenはOnce / Daily・weekly / Interval / Document match / Webhookのいずれか1つ。Document matchは同じProjectのShared Document frontmatterが指定した値に一致すると1回だけ起動する。Webhookは認証済みの外部要求を受け付けるたびに起動する。Project composerのWhen chipから現在のagent・prompt・実行設定を引き継いでTriggerを作成できる。詳細はTriggers
• scheduled follow-up は「予約ターン完了から10分後に再確認する」のようなturn実行に使う。sessionスレッドのcomposerでWhen chipを開き、Send laterで何分後に送るか（1〜1440分、既定10分）を選び、Repeat にcheckを入れると、予約ターンの完了から指定時間待って繰り返す。text-onlyで、replyやattachmentは付けられない。次の実行が控えている間はidle 60分の自動停止は働かずsessionは待機し続ける。繰り返しを終えるにはfollow-upを削除するか、sessionを終了する

AgentのSession内では chat session schedule create self --after 10m "進捗を確認して続ける" を使う。他の既存Sessionへ送る場合は self をUUIDに置き換え、--project <team/project> を付ける。--repeat-after 10m を付けると、予約ターン完了から10分後に繰り返す。--after は正の整数と s/m/h/d（1秒〜30日）、--repeat-after は1分〜24時間を受け付ける。指定時刻は配信可能になる時点で、別ターンの実行中はidleまで待つ。Sessionの新規作成・再開はしない。

一覧は chat session schedule list self、解除は chat session schedule cancel self <reservation-id>。一覧は作成者と can_cancel を返す。AgentはProjectへの現行アクセスを持つ場合、自分が作った予約か、自分のSession宛てのAgent予約を解除できる。人間が作った予約は解除できない。自己予約後は現在のターンだけを通常どおり終え、Sessionは開いたままにする。chat session finish はSessionとその予約を終了させる。同じ作成要求を再送する場合は、返された request_id を --request-id で指定する。

WebUIの予約に表示される In progress は、配信の予約を保持している状態で、実行開始の確認ではない。Runtimeから配信確認が来ない場合も予約を保持し、未受理なら90秒の期限が切れた後に回収・再試行する。配信状況によってさらに待つことがある。保持中は同じSessionの別ターンの配信が待ち、Finishは拒否される。予約の取消とSessionの停止は利用できる。

scheduled follow-upの取消は、その予約の今後の実行を止める。すでに受付済みの仕事は停止しない。WebUIでは終了を確認できた予約をスレッドから除き、今回の取消・すでに取消済み・その他の終了済みを通知で区別する。予約の終了は確認できても受付済みの仕事の状態を確認できない場合は、両方の事実を警告で伝える。

Triggerが起動したSessionの文脈

Project Triggerが新しいSessionを起動すると、そのSessionが受け取る依頼の先頭にTrigger context:の欄が付く。含まれる内容は次のとおり。

• 起動したTriggerの名前とID、スケジュール、このSessionが実行している回
• Triggerに書かれた目的（ある場合のみ Authored purpose）
• 直近の実行履歴（Recent occurrences）: 直近5回と、最新の受付・最新の失敗。各回の状態（受付・理由付きのskip・失敗）と、読むためのRead:コマンド（chat session show <id> --project ... または chat workflow status <run-id> --project ...）
• 受付済みのSessionの回には、そのSessionが残したもの: repositoryごとのPRまたはpush、作成・更新したShared Document、Project Askとその状態、子Sessionとその状態、WorkflowとTriggerの成果。何もなければno result observations, Project Asks, or child Sessions recordedと書かれる

Session範囲のAskは含まれない。履歴がなければNo earlier occurrences are recorded for this Trigger.と書かれる。依頼の文字数上限を超える場合は成果の行が省かれ、more Session results omitted ...と表示される。そのときは前回のSessionをRead:コマンドで読む。

Runtimeの復旧待ち

Claude CodeやCodexが利用上限に達すると、同じ会話・workspace・Workflow Attemptを保持して復旧を待ちます。認証の一時失敗も自動再試行の対象です。必要なら外部ターミナルでloginしてください。Sessionヘッダーに次回の試行時刻を表示します。利用上限の待ち時間は5分、15分、以後30分です。認証切替中の一時失敗は1分、2分、15分、以後30分です。待ち時間には0〜20%の分散があります。自動再試行は同じ復旧episodeの最初の待機開始から最長6時間で、期限以降は新たな自動試行を始めません。実行中の仕事は強制中断しません。失敗理由の変更、Runtime再起動・再接続・reclaimで短い待ち時間や期限はリセットされません。

期限に達した場合や次の待ち時間が期限を超える場合は、失敗終了せず**Waiting for manual retry（手動再開待ち）**になります。会話・workspace・Session/Attempt・途中結果を保持します。Stopで復旧待ちを終了できます。

Retryは保存した会話からその場で一回だけ試行します。6時間枠はリセットせず、期限後の再失敗で自動再試行には戻りません。連打や重複要求で同じ仕事の並列実行を増やしません。画面を開き直しても再試行せず、現在の状態を読み取ります。端末不在ならRuntimeの再接続が必要です。再開時は最新の利用可能な認証を読みますが、実推論に使われたaccountの一致は表示しません。

残高や契約の制限、プロバイダの一時的な拒否では、問題を確認して手動のRetryで一回だけ再開します。Codexでは構造化されたrate limit、容量不足、HTTP 429による内部再試行の枯渇が対象です。これらには自動試行を予定せず、Retryで同じ会話・Workflow Attemptの未完了の仕事を続けます。**Safety check required（安全確認が必要）**は、保存履歴の欠落、未解決の操作、結果不明を区別して案内します。Retryで安全停止を解除したり、元依頼を丸ごと再送したりしません。成果整理だけが残る場合の「作業結果は保存済み、成果整理の復旧待ち」は、Workflow全体の成功確定を意味しません。

関連ページ

• agent repoの構造と、変更が反映されるタイミング（push後の次session）、Runtimeの既定設定は Agents
• projectのstatusとmember管理は Projects
• 時刻・文書条件・外部systemからの起動は Triggers
• PR・pushの提出と記録は コードの提出
• 起動しない・応答が進まないときの切り分けは トラブルシューティング
• コマンドの全体像は CLI