jww-codex-maintenance

Codex のローカル状態を管理する

Xcode の利用可否

このスキルは Xcode では利用できません。手順は Codex Desktop または CLI のローカル状態と、サポートされている Codex のタスク管理操作に依存しますが、Xcode ではこれらを利用できません。Codex ハーネスでのみ使用してください。

診断とクリーンアップは分けてください。ローカル状態が大きいとアプリの動作が遅くなることがありますが、 ファイルサイズを原因の証拠とみなしたり、速度向上を約束したりしないでください。

禁止事項

• セッション JSONL ファイルを移動したり、ローカル状態の データベースを編集したりして、アーカイブを装わないでください。
• 公式の手順に基づく明示的な修復依頼がない限り、Codex データベースを Vacuum、再構築、編集、置換しないでください。
• バックグラウンドプロセス、言語サーバー、開発サーバーを終了しないでください。ユーザーに報告し、判断はユーザーに委ねてください。
• 明示的な承認なしに、トランスクリプト、ログ、メモリ、設定、データベース、認証情報を リポジトリ、共有フォルダー、クラウド同期される場所にコピーしないでください。
• Codex の稼働中のファイルを定期的に変更しないでください。

モードを選択する

デフォルトは Audit です。明示的な依頼があった場合にのみ切り替えてください。ユーザーが Apply を求める場合は「クリーンアップ」「ローテーション」「アーカイブ」「削除」と伝え、 Automate を求める場合は「スケジュール」「定期レポート」と伝えます。「Codex を高速化して」は監査の依頼として扱い、 状態を変更する許可とはみなしません。

• Audit：タスク、ファイル、設定、プロセス、スケジュールされたタスクを変更せず、調査して報告します。
• Apply： references/apply.md を読み、対象を正確に特定して、ユーザーの依頼で許可されたクリーンアップのみを実行します。依頼でカテゴリは許可されていても、その中の個々の対象を区別できない場合は、対象を提示し、変更前に承認を得てください。
• Automate：読み取り専用の監査とレポートを定期的に実行するよう設定します。 スケジュールを設定する前に references/automation.md を読んでください。

依頼が曖昧な場合は、監査を完了して、クリーンアップ案を提示した時点で停止してください。

現在の状態を棚卸しする

1. 環境変数が設定されている場合は CODEX_HOME を使用し、設定されていない場合は ~/.codex を使用します。シェルコマンドで HOME、CODEX_HOME、その他の一般的なシステム変数を再定義しないでください。
2. デスクトップアプリ、Codex CLI、スケジュールされた実行、その他の Codex プロセスが動作中かどうかを確認します。報告し、自動的に停止しないでください。
3. 次の項目について、サイズ、ファイル数、最も古い更新日時と最新の更新日時、最大のファイルを記録します。
   • アクティブなセッションとアーカイブ済みのセッションのトランスクリプト
   • Codex とデスクトップアプリのログ
   • アプリ管理のワークツリーと Git のワークツリー
   • 設定ファイルとプロファイルファイル
   • ローカルデータベースとその -wal および -shm サイドカーファイル
   • メモリ、スキル、プラグイン、スケジュールされたタスクのメタデータ（存在する場合）
4. 利用可能な場合は、ホストがサポートするタスク操作を使って、タスクのステータス、ピン留め状態、経過期間、プロジェクトとの関連付けを一覧表示します。インデックスを書き換えたり、文書化されていないデータベーススキーマを照会したりして、ピン留め状態やタスクの状態を推測しないでください。
5. 負荷の大きい開発プロセス、特に長時間稼働している言語サーバーや開発サーバーを調べます。ただし終了させず、コマンド、作業ディレクトリ、稼働時間、メモリ使用量を報告してください。

macOS では ~/Library/Logs/com.openai.codex/YYYY/MM/DD を含めてください。Codex のセッション トランスクリプトは通常 $CODEX_HOME/sessions に、アーカイブ済みのトランスクリプトは $CODEX_HOME/archived_sessions に、CLI ログは $CODEX_HOME/log に保存されています。 非公開のディレクトリ構成を前提にせず、実行中のインストール環境から他の場所を特定してください。

候補を分類する

各項目を分類し、根拠を説明します。

• タスクのアーカイブ： 古く、ピン留めされておらず、非アクティブで、実行中の作業がないタスクです。7～10日などの経過日数のしきい値は、普遍的なルールではなく、ユーザーの好みとして扱います。
• 大規模なアクティブタスク： ハンドオフして新しいタスクを開始するとよい可能性がある、通常より大きなトランスクリプトです。サイズだけで安全にアーカイブできるとは限りません。
• スケジュール実行のワークツリー： 古く、ピン留めされていない実行で、アプリからタスクをアーカイブできます。頻繁に実行されるスケジュールタスクでは、意図的に多数のワークツリーが作成されることがあります。
• リポジトリのワークツリー： クリーンで未使用であり、完了した作業に関連付けられています。削除を提案する前に、ブランチとリポジトリの所有元を確認します。
• ローテーション可能なログ： 古い、またはサイズが大きく、現在書き込み中ではないログです。
• 無効な設定パス： 設定済みのプロジェクトパスが存在しません。一時的に利用できないボリュームと、実際に不要になったパスを区別します。
• パスエイリアス： 異なる表記が同じ場所を指しています。Windows では、通常のパスと拡張長パスを正規化して比較します。ただし、表示テキストを正規化するだけの目的でアプリの状態を書き換えないでください。

ピン留めされたタスク、実行中またはその他のアクティブな作業、変更のあるワークツリー、現在使用中のログ、不確かなパスはクリーンアップの対象から除外します。ホストがこれらの状態のいずれかを公開できない場合は、安全だと推測せず、対象を不確かとして分類します。

検証して報告する

インベントリを再度確認し、ベースラインと比較します。該当する項目を次のとおり検証します。

• 設定を引き続き解析できる
• データベースを読み取り専用で開け、変更を伴わない整合性チェックに合格する
• 対象のタスクまたはスケジュール実行がアーカイブされ、ピン留めされたタスクに変更がない
• アクティブセッションのバイト数が、意図したアーカイブ分だけ減少した
• アーカイブ済みセッションのバイト数と件数に、一貫した変化があった
• Git に登録されたワークツリーが存在し、変更のあるワークツリーが削除されていない
• 稼働中のログディレクトリが存在し、再起動後に新しいログを作成できる
• パスエイリアスと無効なパスに関する問題が、無関係な設定編集をせずに解決されている

ユーザーにデスクトップアプリを再起動してもらい、サイドバー、アクティブなタスク、スケジュールタスク、および通常の起動を確認してもらいます。実測したディスク容量の変化は、体感速度とは分けて報告します。逸話的な「10倍速くなった」という主張を、期待される結果として繰り返してはいけません。

最終報告には、モード、ベースライン、候補、除外項目、正確な変更内容、検証結果、残るリスクを記載する必要があります。適用モードでは、バックアップの保存場所、復元手順、ユーザーが選択したバックアップの保持または確認に関する判断も記載します。バックアップを暗黙に削除してはいけません。