Codex Config Doctor
プロジェクトで想定される開発作業とCodexの実効設定を対応付け、過不足のある権限、無効な設定、反復的な承認を診断する。
このスキルをタスク実行手順として扱う。常時の制約・規約はシステム指示、AGENTS.md、CLAUDE.mdを優先し、このスキルでは診断の具体的な進め方だけを規定する。
原則
- 診断を読み取り専用で行う。設定変更、依存関係の導入、状態を変えるコマンドの実行は、ユーザーが明示的に依頼するまで行わない。
- 対象は指定されたプロジェクトとする。指定がなければ現在の作業ディレクトリを対象にする。
- タスクやコマンドが指定されていれば最優先で評価する。指定がなければ、プロジェクト内の文書とタスク定義から代表的な開発作業を推定し、推定であることを報告する。
- 秘密値、トークン、資格情報を出力しない。値そのものが診断に不要な設定は存在と参照元だけを記録する。
- 設定名や挙動を記憶だけで断定しない。インストール済みCodexのヘルプ・スキーマを優先し、不明点や更新可能性がある仕様はOpenAI公式Codexドキュメントで確認する。
- 診断チェックリスト を読み、調査項目、判定基準、優先度定義を適用する。
ワークフロー
1. 診断対象を確定する
- プロジェクトルート、OS、Codexの実行形態、ユーザーが重視するタスクやコマンドを特定する。
- 対象が曖昧でも安全に推定できる場合は作業を進め、仮定を記録する。
- 対象の選択によって結論が大きく変わり、安全な推定ができない場合だけ、短い確認質問を行う。
2. プロジェクト情報を収集する
以下を読み取り専用で確認する。
- ルートから対象ファイルまで適用される
AGENTS.md、CLAUDE.md、README、開発ガイド - 言語・フレームワーク・パッケージ管理・ビルドシステムを示すマニフェスト
Makefile、タスクランナー、CI、テスト、lint、format、生成、DB、コンテナ関連の定義- 通常の作業で読み書きするディレクトリ、キャッシュ、ソケット、一時領域、外部リポジトリ
- ネットワーク、GUI、Docker、クラウドCLI、MCP、秘密情報を必要とする操作
実際に使われるコマンドを推定する際は、文書よりタスク定義やCIの実行内容を具体的な証拠として優先する。代表的な操作を「閲覧」「編集」「検証」「依存取得」「外部操作」に整理する。
3. Codex設定を収集する
次の情報源について、存在、読取可否、適用条件、主要設定を記録する。
- 実行時のCodexバージョン、利用可能な診断・設定確認コマンド
${CODEX_HOME:-~/.codex}/config.toml、選択プロファイル、同階層のrules/**/*.rules<project-root>/.codex/config.tomlと<project-root>/.codex/rules/**/*.rules- CLI引数、環境、管理者要件など、確認可能な上位または一時的オーバーライド
- プロジェクトのtrust状態と、プロジェクトローカル設定が実際に読み込まれる条件
ファイルが存在しない、sandboxで読めない、または実効値を確認できない場合も結果として記録する。設定ファイルの単純なマージ結果を推測せず、利用可能ならCodex自身のconfig診断、status、execpolicy検証機能を使って実効状態とルール一致を確認する。
4. タスクと設定を対応付ける
代表的な各操作について、次を表にする。
| 操作 | 根拠となるコマンド | 必要能力 | 関連する実効設定 | 判定 |
|---|---|---|---|---|
| 例: テスト | make test | workspace書込、キャッシュ書込 | sandbox、writable roots、rules | 適切 / 過剰 / 不足 / 不明 |
設定の存在だけでなく、実際の引数列、シェルラッパー、複合コマンド、書込先、ネットワーク先に対してルールが期待どおり一致するか確認する。ルール検証機能が利用できる場合は、代表的な match / not_match 相当のコマンドを読み取り専用で検査する。
5. 不整合を診断する
次の観点を評価する。
- 厳し過ぎる制約: 通常の編集、テスト、生成、キャッシュ利用が不可能、または毎回不要な承認を要求する。
- 許可不足: 必須の読取・書込・ネットワーク・ソケット・外部CLI操作が設定で扱われていない。
- 過剰な権限: プロジェクトに不要な広い書込、ネットワーク、危険コマンド、秘密領域へのアクセスを許可する。
- 無効・不整合: 未対応・非推奨キー、誤った設定レイヤー、trust不足、競合、誤ったprefix、未選択プロファイルにより意図が反映されない。
- 運用上の摩擦: 頻出する安全な操作の承認が反復する一方、危険な操作の境界が曖昧である。
改善案は最小権限と実務上の完遂性を両立させる。広い許可より、対象パス・コマンドprefix・ドメインを限定した案を優先する。設定例を示す場合は、確認済みの現行構文だけを使う。
6. Markdownで報告する
結論を先に示し、次の順で出力する。
- 診断サマリー: 対象、総評、確認範囲、重要な仮定
- 良い点: 根拠付きで維持すべき設定を列挙
- タスク適合表: 操作と実効設定の対応
- 改善すべき点:
High、Medium、Lowの順に記載 - 確認できなかった点: 不在、読取不可、実効値不明を明示
各指摘には以下を含める。
- 問題と影響
- 根拠となるファイルパス、設定キー、コマンド。可能なら行番号
- 最小限の改善案
- 追加確認または検証方法
該当する指摘がない優先度は「該当なし」と書く。診断だけを依頼された場合はファイルを変更せず、提案で終了する。