Claude Code Runnerのsession状態を終了後に削除する

結論：削除flagは既定offのまま、保持要件を先に決める

根拠はClaude Code公式changelogの2.1.268、公式Self-hosted environments、公式runner referenceです。self-hosted environmentは組織のnetwork内でcloud sessionを実行する仕組みで、runner、session、base directoryの関係とLinux・macOS前提を公式文書で確認できます。

消える状態と残す証跡を比較する

対象	--remove-session-stateの扱い	別途決めること
base-dir/_sessions/のsession directory	session終了時の削除対象	復旧・障害調査に必要な最小保持
Git commit / pull request	このflagの対象外	成果物、review、承認、rollback
外部監査・telemetry	保存先と連携次第	event、担当、期間、閲覧権限
runner log	別の保持設定で管理	失敗理由、session ID、削除結果

「sessionが消える」と「監査証跡が消える」は同じではありません。一方で、外部へ転送していない入力・出力・一時ファイルがsession directoryにだけ残っているなら、削除後に戻せません。個人情報、顧客コード、秘密情報、生成物、失敗時の診断情報を分類し、残すべきものをsession directoryの外へ必要最小限で移します。

導入手順：runnerの削除を8ステップで検証する

1. claude --versionとclaude self-hosted-runner --helpでflagを認識するversionと、runnerのbase directoryを記録します。
2. self-hosted environmentがpublic betaであること、Team・Enterpriseのenablement、Owner承認、LinuxまたはmacOS host条件を確認します。
3. 一つの検証sessionを実行し、<base-dir>/_sessions/へ何が作られるか、秘密情報を含めずにfile種別と容量だけ台帳へ残します。
4. session終了前に必要な成果物、Git差分、テスト結果、承認記録、失敗時の最小diagnosticを外部の正本へ送る設計を決めます。
5. 削除flagを検証runnerだけで有効化し、正常終了、失敗終了、キャンセル、再試行、runner停止のケースを一つずつ試します。
6. session ID、終了理由、外部証跡の保存結果、directory削除結果を照合し、削除が早すぎて調査情報を失っていないか確認します。
7. 同じenvironment内の全runnerへ広げる前に、base-dirの権限、容量、sessionの並列実行、異常終了時の残留を確認します。
8. 保持期間、例外申請、削除flagの変更承認、定期監査、rollback方法を文書化してから段階展開します。

削除の成功だけを合格条件にしません。成功したsessionのworktreeが消えること、失敗したsessionの原因を外部logから追えること、session終了処理が途中で止まった時に残留を検出できることを同時に確認します。容量削減が目的でも、事前に保存すべき情報を決めずに削除すると、復旧時間と再実行コストが増えます。

保持・料金・制限を混同しない判断軸

保持設計は料金設計とは別です。base directoryの容量、runner台数、ログ転送、object storage、監視の費用は組織の基盤コストです。--remove-session-stateがprovider料金、Claude Codeのモデル料金、self-hosted environmentの契約条件を変えるという公式保証はありません。費用を見積もる時は、一時領域、外部ログ、成果物、再実行時間を別に記録します。

制限も確認します。公式referenceではrunnerにbase-dir、API URL、environment secret、並列実行などの運用条件があり、flagとenvironment variableの優先順位にも注意が必要です。flagが認識されても、全runnerが同じbase-dir、version、権限とは限りません。fleetへ展開する前にhost、container image、起動引数、環境変数、変更時刻をそろえます。

self-hosted environmentは、開発者の端末で動かす通常sessionやRemote Controlと同じものではありません。公式overviewは、cloud sessionが組織のrunnerで実行される仕組み、quickstartは最小の一台構成を説明しています。Miraigentのbackground sessionへのattach記事や監査ログ設計の記事と組み合わせ、再接続と証跡の責任を分けてください。

チェックリスト：削除を有効にする前に

□2.1.268以降か　□flagの既定offを確認したか　□base-dirと_sessionsの構造を記録したか　□入力・出力・一時ファイルを分類したか　□Git・監査・runner logの保存先を決めたか　□正常・失敗・cancel・再試行を試したか　□session IDと削除結果を照合したか　□並列runnerで残留を確認したか　□例外申請と復旧責任者を決めたか　□fleet展開・rollback・次回棚卸し日を承認したか。

よくある質問

--remove-session-stateは既定で有効ですか？

いいえ。2.1.268の公式changelogではdefault offです。削除を標準化する前に、保持要件と外部証跡の保存を検証します。

削除すると監査ログも消えますか？

flagが対象とするsession directoryと、外部の監査・telemetry・Git履歴は別管理です。ただし外部保存していない情報は失われ得るので、保存処理の成功を削除より先に確認します。

Windowsのrunnerで使えますか？

公式self-hosted referenceはLinuxまたはmacOS hostを前提にしています。Windows端末を利用する場合はunsupportedなrunner構成にせず、公式のhost条件とcontainer運用を確認します。

公式情報と無料診断

更新内容は公式changelog、仕組みは公式overview、flag・環境変数・metricsは公式referenceを公開直前に確認しています。Miraigentの無料診断では、runner、保持、監査、停止条件を企業の運用表へ落とし込みます。