コミット済みのシンボリックリンクが worktree の外を指す — AI に並列作業を預ける前のリポジトリ点検

危険なリンクだけを洗い出す監査スクリプト

全てのシンボリックリンクを消す必要はありません。正当なリンク（リポジトリ内の相対リンクなど）は日常的に使われます。洗い出したいのは「リポジトリの外を指すもの」「絶対パスのもの」「.git や .claude の内部を指すもの」だけです。

git ls-files -s で 120000 のエントリを取り、blob の中身（行き先）を正規化して、リポジトリルートの外へ出るものを危険と判定します。ワーキングツリーではなくインデックスを見るので、checkout 前の clone 直後でも走ります。

#!/usr/bin/env bash
# audit-symlinks.sh — コミット済みシンボリックリンクのうち危険なものを列挙する
# 使い方: リポジトリのルートで  bash audit-symlinks.sh
set -euo pipefail
 
ROOT="$(git rev-parse --show-toplevel)"
DANGER=0
 
# 120000（シンボリックリンク）のエントリだけを取り出す
git ls-files -s | awk '$1 == "120000" { $1=$2=$3=""; sub(/^ +/,""); print }' \
| while IFS= read -r path; do
    # blob の中身 = リンクの行き先の文字列
    target="$(git cat-file blob ":${path}")"
 
    verdict=""
    case "$target" in
      /*) verdict="絶対パス" ;;                        # / から始まる
    esac
 
    # リンクのある位置を基準に行き先を正規化し、ルート外なら危険
    linkdir="$(dirname "${ROOT}/${path}")"
    resolved="$(cd "$linkdir" 2>/dev/null && \
                python3 -c "import os,sys;print(os.path.normpath(os.path.join(os.getcwd(), sys.argv[1])))" "$target" 2>/dev/null || true)"
    case "$resolved" in
      "$ROOT"|"$ROOT"/*) : ;;                          # ルート配下なら許容
      *) [ -n "$verdict" ] || verdict="ルート外を指す" ;;
    esac
 
    # .git / .claude の内部を指すものは無条件で危険
    case "$resolved" in
      "$ROOT"/.git|"$ROOT"/.git/*|"$ROOT"/.claude|"$ROOT"/.claude/*) verdict="管理ディレクトリを指す" ;;
    esac
 
    if [ -n "$verdict" ]; then
      printf '⚠️  %-40s → %s  [%s]\n' "$path" "$target" "$verdict"
      DANGER=1
    fi
  done
 
exit "$DANGER"

このスクリプトは危険なリンクを 1 件でも見つけたら終了コード 1 を返します。CI やフックで if ! bash audit-symlinks.sh; then … と受けられるようにするためです。実際に手元の 4 リポジトリへ流したところ、危険判定は 0 件でした。0 件を確認できたこと自体が収穫で、「見ていなかった」から「見て問題なかった」へ状態が変わりました。

何を「危険」とみなすか — 判定の基準

判定の線引きを表にまとめます。ここは正当なリンクを巻き込みすぎないためのチューニングどころです。

一点、注意点を正直に書いておきます。この監査は「コミットされたリンク」を見るものです。実行時に生成されるリンクや、core.symlinks の解決タイミングが絡む TOCTOU 的な隙まではカバーしません。監査は入口を狭める一手であって、辿り自体を止める修正の代わりにはなりません。だからパッチ適用と監査は、片方ではなく両方を回すのが私の考えです。

隔離してから worktree を作る

信頼度の低いリポジトリを開くなら、clone の時点で辿りを回避できます。core.symlinks=false で clone すると、リンクは本物のリンクではなく、行き先の文字列を中身に持つ通常ファイルとして展開され、OS に辿られません。

# 信頼できない clone は、まずリンクを「ただのテキスト」として落とす
git -c core.symlinks=false clone "$REPO_URL" ./untrusted
 
cd ./untrusted
bash /path/to/audit-symlinks.sh || {
  echo "危険なリンクを検出。worktree 作成を中止します。"
  exit 1
}
 
# 監査を通ってから、必要ならリンクを有効化して worktree を切る

信頼できない clone を扱うときの順序は、次の 4 つに固定しています。

1. 外部由来のリポジトリは core.symlinks=false で clone する
2. audit-symlinks.sh を流し、危険判定が出たら worktree を切らずに止める
3. 通ったら、ビルドに必要なリンクだけを有効化する
4. その状態で worktree を切り、Claude Code に渡す

core.symlinks=false は正当なリンクにも影響します。リンクを前提にビルドするプロジェクトでは、この設定のままだと動きません。信頼できない clone だと判断したこの場合は、まず封じる側に倒し、通ってから戻す、という順序で使います。私はこの clone を外部由来のリポジトリにだけ適用し、自分の管理下のリポジトリは通常 clone にしています。全部を締めると正当な用途まで壊すので、締める対象を出所で切り分けるのが現実的でした。

Claude Code に worktree を量産させる運用そのものについては、Claude Code worktree で並列開発を加速するで基本の流れを扱っています。本記事はその前段に置く「点検」の層だと考えてください。

clone と CI に点検を差し込む

点検は、思い出したときに手で流すのではなく、経路に固定してこそ効きます。差し込みどころを整理します。

worktree 作成をラップする最小の形はこうなります。監査に通らなければ、その枝は開きません。

safe_worktree_add() {
  local branch="$1" dir="$2"
  bash "$(git rev-parse --show-toplevel)/audit-symlinks.sh" || {
    echo "監査に失敗。worktree を作成しません: $dir"
    return 1
  }
  git worktree add "$dir" "$branch"
}

権限の面から無人実行を締める話は無人実行で auto モードの確認要求を止めずに捌くに、破壊的コマンドの事前確認に助けられた記録は空の変数と rm -rf の夜にまとめてあります。ファイルシステムの経路を締める本記事とは別のレイヤーですが、無人でリポジトリを触らせる運用では両方が要ります。

Before / After — 点検を挟む前と後

変わったのは、コードよりも順序でした。

追加したスクリプトは数十行、CI ジョブは 1 つで、worktree 運用のコード全体から見れば 1% にも満たない量です。それで「見ていなかった経路」が「見て、通ったら開く経路」に変わりました。実装の重さと、防いでいる事故の重さが釣り合っていない――こういう非対称な投資を見つけられると、少し嬉しくなります。

おわりに

まず一つだけ試すなら、いま AI に触らせているリポジトリのルートで audit-symlinks.sh を一度走らせてみてください。多くの場合、結果は 0 件です。その 0 件は「危険がない」ことの確認であり、「見ていなかった」から一歩進んだ証でもあります。危険が出たら、その 1 件が worktree を切る前に見つかったこと自体が、点検を経路に固定する理由になります。

私自身、セキュリティは詳しいとは言えず、この点検も完全ではありません。それでも、パッチに守ってもらうだけでなく、自分の側でも一枚挟んでおく。その小さな習慣を、共有できればと思って書きました。お読みいただきありがとうございました。