codex-cleanup

Codex のクリーンアップ

タスク履歴、SQLite の状態、インストール済みリリース、または実行中の処理を破損させることなく、測定されたローカルストレージまたはメモリを取り戻します。まず監査し、対象を正確に提示してから、ユーザーが承認した範囲のみを変更します。

これらの境界を守る

• 監査と計画は読み取り専用として扱います。
• 現在または適用可能な以前のユーザー指示に明示的なクリーンアップ範囲がある場合、その範囲の権限として扱います。それ以外の場合は、正確な対象、子孫、推定バイト数、可逆性、再起動が必要かどうかを示してから確認を得ます。
• タスクを恒久的に削除するには、サポートされているタスクのライフサイクル機能を使用します。提示または呼び出す前に、ヘルプ、スキーマ、または主要なプロトコルドキュメントで、インストール済みの正確なインターフェースを確認します。便宜的な CLI コマンドを捏造してはならず、ロールアウトファイルやタスク行を直接削除してはなりません。
• データベースのチェックポイント、コピー、またはバキュームの前に、対象データベースへアクセスできるすべてのプロセスを停止します。これには、解決された Codex ホームを共有するすべての Desktop、CLI、IDE 拡張機能、app-server、ヘルパーセッションが含まれます。タスクがアイドル状態に見える場合も同様です。有効な Codex ホームが異なると証明できる場合のみセッションを開いたままにできます。それ以外は書き込み可能なプロセスとして扱います。
• 現在の実行プロセスやその祖先プロセスを終了してはなりません。現在の実行が対象の Desktop または CLI のプロセスツリー内にある場合は、次の正確な操作を準備し、別のプロセスから続行するか、ユーザーに終了してもらいます。
• .tmp、plugins、worktrees、shell_snapshots、状態データベース、認証情報、設定を一括削除してはなりません。個々の対象について、所有者と古さを事前に確認します。
• 無関係なユーザーの変更やデータは保持します。対象が Codex に関連付けられない場合、または安全なライフサイクルが不明な場合は停止します。

監査

1. 明示的なパス、次に CODEX_HOME、最後にプラットフォームのユーザーホームにある .codex ディレクトリの順に、有効な Codex ホームを解決します。解決されたパスを記録します。
2. このスキルディレクトリから scripts/audit_codex_home.py を実行します。これは読み取り専用で、トップレベルのサイズ、履歴の経過期間、SQLite の空きページ、リリースキャッシュの候補、関連するプロセスツリーを報告します。結果を保持または比較する場合は --json を使用します。追加のデータベーススキャンを許容でき、クライアントが停止済みの場合に限り、--quick-check を追加します。通常のページ指標は、メインファイルのヘッダーのみから取得されます。--quick-check の場合、スクリプトは該当する実行時プロセスを検出すると処理を拒否し、一時コピーをチェックします。そのため、Codex ホーム内にデータベースのサイドカーファイルが作成されたり変更されたりすることはありません。プロセス一覧には意図的に引数と環境変数が含まれていないため、各プロセスがどの Codex ホームを使用しているかは証明できません。実行時プロセスの表示は保守的に解釈してください。
3. 互換性のある Codex 実行ファイルに読み取り専用の doctor コマンドがある場合は、それを実行し、変更前のロールアウト／データベースの整合性情報を取得します。アクティブな Desktop または CLI が使用する実行ファイルを優先し、シェルの codex が同じビルドだと決めつけてはなりません。
4. 候補を解釈したりクリーンアップを実施したりする際は、references/storage-contract.md を読みます。バージョンに関する記載がインストール済みビルドと一致しない場合は、インストール済みのヘルプまたは現在の主要なソースを再確認します。
5. 測定した回収可能なバイト数と、応答性への改善見込みに基づいて機会を順位付けします。ディスクストレージ、データベース内部の空きページ、常駐メモリは分けて扱い、誤解を招く合計にまとめてはなりません。

実施前に監査結果を報告します。重要なカテゴリごとに、現在のサイズ、候補サイズ、提案する操作、リスク／再起動の要否、既定の推奨事項を含めます。

承認済みのクリーンアップ計画を作成する

証拠によって裏付けられるアクションのみを選択します。

• タスク履歴： 経過時間、アーカイブ状態、プロジェクト、またはユーザーが指定した条件に基づいて、対象となるルートタスク ID のみを選択します。各ルートタスクの子孫タスクとサブエージェントタスクを展開し、その一覧を表示します。ライフサイクル API が非アクティブと報告した場合、または完了が別の方法で証明された場合にのみ、タスクを完了済みとして扱います。古いスポーンエッジのフラグだけを信用しないでください。現在のタスクと、アクティブなすべての書き込みプロセスを除外します。
• ランタイムメモリ： 所有元となる Desktop または CLI のツリー、アクティブな作業、現在のプロセスの親子関係、および古い残存ヘルパーを特定します。アプリまたは CLI を正常に終了して再起動する方法を優先します。所有元の終了後も残るヘルパーに限り、対象の PID を正確に提示します。
• スタンドアロンリリース： current の参照先を解決します。それを維持し、デフォルトでは、異なるロールバックリリースのうち最も新しいものも維持します。インストーラーとアップデーターが停止している間に、ほかの完全なリリースディレクトリのみを検討します。
• ログデータベース： 測定した未使用ページの解放によってファイルシステムの空き容量を十分に確保できる場合は、コンパクションを推奨します。見込まれる節約量がわずかな場合は、実施を見送ります。SQLite の VACUUM は保持対象の論理行を維持し、ファイルを再構築して未使用ページをファイルシステムに返します。これは、タスクの削除やログの保持期間設定の代わりにはなりません。安全性を確保するためのコピーと、SQLite の一時的な書き換えの両方に十分な作業領域が必要です。コンパクションを承認、引き継ぎ、または実施する前に、workflows/compact-log-database.md を読み、その手順に従ってください。
• その他のキャッシュ： インストール済みバージョンで所有関係とクリーンアップの仕様が文書化されている場合、またはユーザーが確認後に破棄可能なファイルを正確に指定して承認した場合に限り、対応します。

アーカイブを空き容量の確保として説明しないでください。通常、アーカイブはタスク履歴を移動してインデックスを更新するだけで、ロールアウトの内容は削除されません。

安全な順序で適用する

承認されたアクション種別と、その必須の前提条件のみを、以下の順序で実行してください。履歴のみのクリーンアップには、データベースの圧縮、キャッシュの削除、または不要なシャットダウンは必要ありません。

1. 発見して検証したネイティブのタスク削除機能（app-server の thread/delete など）を使用して、承認済みのタスクを完全に削除します。実行ファイルまたは接続された機能、バージョン、メソッド名、発見の根拠を記録します。承認済みの完了済み子孫タスクも含めます。一貫性と再試行の順序に従って、ライフサイクル操作により、ロールアウトファイル、インデックス、ログ、キュー、メモリ、目標、動的ツール、スポーンエッジを更新させます。API が外部から参照されているフォークの削除を拒否した場合は、その旨を報告し、対象範囲を広げるかユーザーに確認します。チェックを回避してはいけません。検証済みの呼び出し可能な削除インターフェースがない場合は、不足している機能を明記した計画の作成で止めます。メソッドを、あると決めつけた codex delete コマンドに置き換えたり、ファイルシステムや SQLite の削除に切り替えたりしてはいけません。
2. パリティ診断と履歴インベントリを再実行します。欠落、重複、不一致、または古い状態が見つかった場合は、優先度の低いクリーンアップに進まずに停止します。
3. データベースへのアクセスを停止します。ユーザーに作業中のタスクを完了または停止し、解決済みの Codex ホームを共有するすべての Desktop、CLI、IDE 拡張機能、app-server、ヘルパーのセッションを終了するよう依頼します。関連するすべての PID が終了したことを確認します。セッションがアイドル状態に見えることから、安全だと判断してはいけません。承認済みの残存 PID のみに正常終了シグナルを送信します。強制終了へのエスカレーションには、別途明示的な権限が必要です。
4. 停止状態のまま、承認済みの古いリリースディレクトリを削除します。削除の直前に current の参照先を再解決し、参照先が変わっていた場合、または削除候補のいずれかが参照先と一致する場合は中止します。
5. 承認済みのデータベース圧縮については、圧縮ワークフローのセクション 1〜5 を実行します。オフライン条件の確認、復旧用コピー、論理ベースライン、PRAGMA integrity_check、WAL チェックポイント、VACUUM、再オープン前の確認を行います。いずれかの条件確認に失敗した場合や、結果が曖昧な場合は中止します。ワークフローを単なる VACUUM コマンドに縮小してはいけません。
6. 段階的に再起動します。圧縮後は、そのワークフローのセクション 6 に従います。圧縮しない場合は、対象のクライアントを通常どおり再起動します。保持されたタスクを検証してから、同じオプションで監査を再実行し、測定したバイト数とプロセス数をベースラインと比較します。

現在の実行をオフライン状態にできない場合は、オフラインでの完全な引き継ぎ情報を作成した時点で停止します。正確に解決したパス、承認済みの対象、除外した現在の祖先、前提となる終了確認、コマンドまたは API 操作、検証方法、復旧手順を記載してください。監視されない破壊的なジョブを予約してはいけません。

完了

監査のみの依頼では、調査結果と実行可能な提案を提示して完了します。クリーンアップの依頼では、承認済みの操作が完了するか、正確なオフライン引き継ぎ情報が整った時点で完了とします。該当する結果を報告してください。

• カテゴリ別の回収バイト数と、残りのディスク空き容量
• 削除したタスク（子孫タスク数を含む）と、意図的に保持したタスク
• データベースの整合性と、ロールアウト／データベース間のパリティ結果
• 保持および削除したリリースディレクトリ
• 停止した、または依然としてアクティブなランタイムプロセス
• スキップした対象、阻害要因、復旧用アーティファクト

測定結果と推定値、推奨事項を明確に区別してください。