AI エージェント CLI（Claude Code / Codex 等）の設定ファイルは、ツール自身が設定変更・信頼情報・通知状態などを頑繁に自動書き換える。こうしたファイルを dotfiles で管理する場合、方式選択が壊れにくさを左右する。

判断基準

• 定番の「リポジトリに実体を置き、ホームへ symlink を張る」方式は、ツールが設定を temp ファイル + atomic rename で書き換えると symlink 自体が普通のファイルに置換され、以後の変更がリポジトリに一切反映されなくなる「静かな分離」リスクを持つ。書き換え方式はツール実装の内部事情で、バージョンアップで変わりうるため事前検証しても恒久の保証にならない。
• bare リポジトリ方式（git ディレクトリをホーム外の専用パスに置き、work-tree をホームに向けた alias で操作）なら、ファイルは実位置の実ファイルのままなので、ツールがどう書き換えても壊れない。ドリフトは diff で見え、気づいた時に commit する運用になる。
• untracked を非表示にする設定（status.showUntrackedFiles を no）が前提。ホーム直下全部が候補に見えると運用にならない。新規ファイルは明示的に add する規律とセットで採用する。
• chezmoi 等の専用ツールはテンプレート・複数マシン差分・秘密管理が必要になった時点で検討する。単一マシン・少数ファイルのうちは素の git の方が透明で安い（可逆・最小から始める）。

秘密の分離

シェル rc に直書きされがちな API キー等は、追跡対象化の前に untracked のローカルファイル（rc 末尾で存在時のみ source する .zshrc.local 等）へ分離する。復元手順には「このファイルは手で再作成」と明記し、何のキーを置くかは名前だけ残す。初回 commit 前に staged 全体を秘密らしい文字列で走査する。

検証

• 新しい対話シェルで alias が効き、status がクリーンであること。
• 分離した秘密がローカルファイル経由で引き続き環境変数に載ること。
• ツールに設定を書き換えさせた後、変更が diff に現れること（symlink 方式だとここで分離を検出できる）。