pnpm 12.11.0 Skills の権限を実測：一度承認すると、具体的に何を意味するのか？

説明： pnpm v12.11.0 のソースコードと特定バージョンのドキュメントをもとに、Skills の検出範囲、承認、リンクの挙動を整理し、独立した合成モデルで重要な分岐を検証します。依存関係のアップグレードや権限管理の方法を評価する際の参考にしてください。

検出と権限の境界

最初は、問題を単純に考えていました。依存パッケージに SKILL.md が増えたら、pnpm がインストール時に Agent のディレクトリへ配置するか、まったく何もしないかのどちらかだろう、と。pnpm 12.11.0 の固定バージョンのソースを追ってみると、その間には検出、権限判定、リンク作成という段階がありました。この境界を把握することが、「一度承認する」とは何を意味するのかを判断する鍵です。

まず検出ロジックを追いました。依存ツリー内に Skill ファイルがあれば、承認フローに進むものだと思っていました。しかし、スキャン範囲はもっと限定的でした。pnpm が確認するのは lockfile 内の各 workspace importer の直接依存で、Skills ディレクトリも一階層だけをスキャンします。間接依存はこの検出経路に含まれません。「依存ツリーにファイルがある」ことと「pnpm がそれを検出する」ことは、同じではありません。

次に、インストール、リンク、Agent による読み込みを分けて考えました。パッケージ内のファイルは、すでに依存ディレクトリに置かれている場合があります。権限の状態によって、pnpm がそのファイルから対象ディレクトリへのシンボリックリンクを作成するかどうかが決まります。その後、Claude Code やほかの Agent が読み込むか、どう扱うかは、それぞれのクライアント次第です。pnpm のソースコードが処理するのはリンクであり、Skill の内容を解析したり実行したりするわけではありません。

権限の状態には、承認待ち、拒否、承認済みがあります。承認はパッケージ単位の操作で行われ、pnpm approve はビルドスクリプトと Skills の権限の両方に関わります。これは、ファイルを一つずつ審査することを意味しません。ビルドスクリプトの権限と permissions.skills は別々の権限領域です。パッケージのビルドスクリプトが承認されても、Skill の内容が個別に審査されたことにはなりません。

特に立ち止まって確認したのは、承認の適用範囲です。v12.11.0 の公式ドキュメントによれば、パッケージ単位の承認はその依存パッケージに含まれるすべての Skills に適用され、以後のバージョンにも引き継がれます。アップグレード時は、新バージョンで指示内容が変わっていないか注意が必要です。以前の承認状態が引き続き有効でも、新バージョンで Skill が追加されたり、書き換えられたりする可能性があります。

workspace 内に複数の利用可能なバージョンがある場合、ソースコードはインストール済みで条件を満たす registry バージョンのうち、最も高いバージョンを選択します。どの内容が実際にリンクされるかに影響するため、package.json のバージョン範囲を見るだけでは不十分です。アップグレード後に Agent が何を読み込む可能性があるかを判断するには、実際に選択されたパッケージのバージョンと、そこに含まれる Skill も確認する必要があります。

対象ディレクトリにも明確な条件があります。v12.11.0 は、CLAUDECODE、CURSOR_AGENT、GEMINI_CLI の環境変数、または workspace 内に既存の Agent Skills ディレクトリがあるかどうかを参照します。skills.dirs で明示的に上書きすることもできます。明示的な設定が空の場合、Skills は無効になります。承認時に対象ディレクトリが自動検出されなければ、対象がないというエラーになります。

# pnpm-workspace.yaml
skills:
  dirs:
    - .claude/skills
    - .cursor/skills

当初は、権限を取り消せば関連ディレクトリ内の内容も削除されると思っていました。しかし、ソースコードと独立したファイルシステムモデルが示す境界は、もっと限定的でした。モデルでは、pnpm が作成したリンクは削除されますが、手動で作成したローカル Skill はそのまま残ります。また、対象パスが実ディレクトリに占有されている場合、そのディレクトリが置き換えられることはありません。パッケージの削除や対象ディレクトリの欠落といった分岐も、それぞれのリンク削除とエラー処理のロジックに沿って理解する必要があります。

合成モデルとテスト結果

これらの分岐を具体化するため、Node 22.16.0 の標準ライブラリを使った独立した合成ファイルシステムモデルを作成しました。仮の依存パッケージ、合成 SKILL.md、シンボリックリンクを作成し、内容のフィンガープリントを計算します。8つのケースでは、承認待ち、拒否、承認、アップグレード後の Skill 追加、承認の取り消し、パスの競合、間接依存のみの場合、自動検出される対象ディレクトリがない場合をそれぞれ確認しました。

8ケースすべてがモデルを通過しました。アップグレードのケースでは、内容のフィンガープリントが変化し、2つ目の Skill リンクが追加されることを確認しました。最初にモデルを実行したときは、「リンク数がゼロであること」を承認済み Skill があるかどうかの判定に使っていたため、1ケースが失敗しました。その結果、「対象ディレクトリがない」ケースを誤判定していました。原因を特定した後、承認済み Skill の数を個別に確認するよう修正し、再実行すると8ケースすべてが通過しました。

リポジトリの確認と適用範囲

リポジトリを確認する際は、まず pnpm permissions または pnpm permissions list で権限を確認し、workspace の設定と照らし合わせるとよいでしょう。依存関係をアップグレードした後は、新バージョンに含まれる Skills ファイルとその差分を確認します。指示内容の変化を特に重視するプロジェクトでは、依存関係のバージョンを固定し、CI で SKILL.md を比較する方法もあります。

pnpm permissions
pnpm permissions list

境界 / 制限

今回の分析は pnpm v12.11.0 のソースコードと特定バージョンのドキュメントを基準とし、テストには Node で単独実行する合成モデルを使っています。対象範囲はファイルシステムの挙動です。モデルは pnpm CLI、実際のインストールや更新、Agent とは連携していません。また、クライアント側の検出と実行のルールは、それぞれのバージョンによって変わる可能性があります。pnpm 12.11.1 での環境識別の変更を、12.11.0 の機能として扱うべきではありません。パッケージ単位の承認が後続バージョンにも適用されるという信頼範囲は、アップグレード時のレビューで考慮すべき設計上の境界です。

参考リンク： pnpm v12.11.0 ソースコード · pnpm v12.11.0 ドキュメント