Claude Media
Claude CodeでmacOSの権限が更新で消える原因と再許可の手順
Claude CodeTips

Claude CodeでmacOSの権限が更新で消える原因と再許可の手順

Claude Codeの更新のたびにmacOSの許可ダイアログが再び出る原因は、TCCが許可をバージョン付きパスに結び付けるためです。確認コマンドと再許可の手順を示します。

読了目安 約10分

Claude Codeを自動更新したあと、macOSが「"2.1.273"がほかのAppのデータへのアクセスを求めています」と聞いてくる。許可したはずのフォルダーで、またOperation not permittedが出る。この症状はGitHubで複数のissueとして報告されていて、原因は共通しています。macOSの許可管理(TCC)が、許可を署名ではなく実行ファイルのパスに結び付けているためです。

更新のたびに新しいバージョンのディレクトリができるので、許可はそのたびに振り出しに戻ります。この記事では、仕組み、自分の環境で確かめるコマンド、更新後の再許可、頻度を減らす手段を順に書きます。

更新のたびに許可が消えるときに起きていること

報告されている症状は2系統あります。

  • ファイルとフォルダー、フルディスクアクセスの許可が毎回求められる。バックグラウンドセッションが~/DocumentsなどでOperation not permittedになる
  • ローカルネットワークの許可が消え、LAN内のホストへの接続がNo route to hostで失敗する

前者はissue #94878と#49282、#89722、後者は#90412が扱っています。#94878では、ユーザーのTCCデータベースに~/.local/share/claude/versions/2.1.232から2.1.273まで、バージョンごとの行が並んでいたと報告されています。一度与えた許可は、更新後に保持されません。

#94878のコメントでは、システム設定の一覧に古いバージョンが別々のアプリとして並ぶ様子も報告されています。ひとりはフルディスクアクセスに13個のバージョン、もうひとりはファイルとフォルダーに8個のバージョンが並んだと書いています。多くは、更新処理がすでに消したバイナリを指していて、アイコンは空白です。

原因はバージョン付きのパスにある

ネイティブインストーラーは、実行ファイルを~/.local/share/claude/versions/<バージョン>に置きます。~/.local/bin/claudeはそこへのシンボリックリンクです。TCCはシンボリックリンクをたどった先の実体のパスで主体を識別します。更新で新しいパスができると、macOSには別のアプリに見えます。

#49282の報告者が示したcodesignの出力では、署名は更新を越えて変わっていません。識別子はcom.anthropic.claude-code、チームIDも同じです。つまり署名の問題ではなく、パスの問題です。

#89722には、ログの裏づけがあります。tccdのログにidentifier_type=Path、identifier=~/.local/share/claude/versions/2.1.245というイベントが記録され、バンドルに属さない実行ファイルとして扱われていました。ダイアログの題名にバージョン番号が出るのは、表示に使えるバンドル名がないからです。

ClaudeCode.appを経由すれば安定するはずだが

Claude Code側にも対策の仕組みがあります。バックグラウンドセッションは、実行ファイルを~/.local/share/claude/ClaudeCode.appにハードリンクし、そのバンドル経由で自分を再起動します。バンドルの識別子は固定なので、許可がバージョンを越えて残る設計です。

ところが、報告ではこの経路から外れる場面が3つ挙がっています。

  1. スペアのpty-host: --bg-spare付きで先に起動しておく待機プロセスは、バンドル経由の再起動を飛ばします(#94878)
  2. 対話式のCLI: 普段ターミナルで使う対話セッションは、そもそもバンドルを使いません(#89722)
  3. ハードリンクの名前解決: 同じプロセスでも、カーネルが返すパスがバンドル側とバージョン側で揺れます(#94878、#89722)

3つ目が厄介です。#89722の再現では、1つのイノード(ファイルの実体)に2つの名前があると、同じプロセスのパスを何度か問い合わせたとき、2つの名前が混ざって返りました。バンドルを通っても、バージョン付きのパスで記録される場合があるということです。

公式の説明と実際のずれ

changelogのv2.1.153には、macOSのバックグラウンドエージェントが「Claude Code」としてPrivacy & Securityに現れ、アップグレードを越えて許可を保持する、という記載があります。agent viewのドキュメントも同じ趣旨です。ネイティブインストーラーなら項目名はClaude Codeになり、許可は更新後も続く。HomebrewやnpmではバイナリのパスがそのままUIに出て、更新後に再許可が必要になる場合がある、と書かれています。

#94878のコメントは、この説明と一致しない環境を報告しています。v2.1.293のネイティブインストールで、約19時間分のTCCログにClaudeCode.appは0回、バージョン付きパスのリクエストは63回だったそうです。責任プロセスはversions/2.1.293、識別はtype: 1(パス型)でした。

対照的に、Claude Desktopから起動したセッションはDesktopに同梱のclaude.appが責任プロセスになり、type: 0の行が1つできて更新後も残るとのことです。ただしローカルネットワークは別で、デスクトップ側のヘルパーも~/Library/Application Support/Claude/claude-code/<バージョン>/claude.appというバージョン付きのバンドルパスに許可が結び付き、20行以上が溜まったと#90412は報告しています。

要するに、どの入口から起動したかで許可の主体が変わります。

起動の入口許可の主体(報告ベース)更新後
ターミナルの対話式CLI許可の主体(報告ベース)versions/<バージョン>のパス更新後許可が外れる
claude agentsのバックグラウンドセッション許可の主体(報告ベース)ClaudeCode.appまたはバージョン付きパス更新後スペア経由だと外れる
Claude Desktopのセッション(ファイル系)許可の主体(報告ベース)同梱のclaude.app更新後残ると報告
Claude Desktopのセッション(ローカルネットワーク)許可の主体(報告ベース)バージョン付きのclaude.app更新後外れると報告

自分の環境で原因を確かめる

症状がパスの問題かどうかは、ログとstatで見分けられます。まず、TCCの判断に使われた責任プロセスのパスを引きます。

log show --last 1d \
  --predicate 'subsystem == "com.apple.TCC" AND eventMessage CONTAINS "AUTHREQ_ATTRIBUTION"' \
  | grep responsible_path

出力のresponsible_pathがClaudeCode.appではなくversions/<バージョン>を指していれば、報告と同じ状態です。ログの保持期間は短く、#94878のコメントでは約19時間分でした。症状が出た直後に実行します。

次に、ハードリンクの状態を見ます。

stat -f "%i %l %N" \
  ~/.local/share/claude/ClaudeCode.app/Contents/MacOS/claude \
  ~/.local/share/claude/versions/*

1列目のイノード番号が一致し、2列目のリンク数が2なら、バンドルと現行バージョンが同じ実体です。#89722の環境では、バンドル側が12バージョンぶん古い状態も観測されています。ls ~/.local/share/claude/versions/で残っているバージョンも確かめてください。

更新後に許可を取り直す手順

根本の修正が入るまでは、更新後に手動で整える運用になります。

  1. システム設定の「プライバシーとセキュリティ」を開く
  2. 症状に応じて「ファイルとフォルダ」「フルディスクアクセス」「ローカルネットワーク」のどれかを開く
  3. 現行バージョンの行を有効にする。行がなければ、次にClaude Codeが保護された場所へ触れたときのダイアログで許可する
  4. 空白のアイコンで、実体のないバージョンの行を「−」ボタンで削除する

4は#94878のコメントで、ファイルとフォルダーの古い6行を手で消した例があります。一方、#90412はローカルネットワークの一覧に行ごとの削除UIがなく、一覧は増える一方だと報告しています。ペインによって削除できるかが違う点に注意してください。

ドキュメントの案内どおり、保護フォルダーを読むバックグラウンドセッションには、フルディスクアクセスの付与も手段になります。ただし#94878の本文では、バンドルにフルディスクアクセスを付けてもバージョン名のダイアログが出続けたと書かれています。付与の効果は、どのプロセスが責任主体になるかに左右されます。

ローカルネットワークは、macOS 15以降でシステムが許可を求める仕様です。バックグラウンドセッションで最初にLANアドレスへ接続したとき、Claude Code向けの許可ダイアログが出ます。更新後にルーターやVPNが原因に見えるNo route to hostが出たら、ネットワーク設定を疑う前にこの一覧を見るのが近道です。

頻度を減らす選択肢とその限界

許可が消える回数は、更新の回数と同じです。更新を止めれば減りますが、手段は選ぶ必要があります。

~/.claude.jsonのautoUpdates: falseは、ネイティブ更新を止められなかったという報告があります。経緯はautoUpdatesが無視される報告と確実な止め方にまとめています。#94878のコメントによれば、止まるのはDISABLE_AUTOUPDATER=1だけです。

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

この設定はバックグラウンドの更新確認だけを止めます。手動のclaude updateは動くので、更新の時期を自分で選べます。手動更新も含めて止めるDISABLE_UPDATESは、配布を自前で管理する組織向けです。チャンネルの選び方や更新全般はClaude Codeアップデートの方法が詳しい説明です。

代償もあります。更新を止めると、セキュリティ修正の取り込みも自分の手動更新まで遅れます。コメントの報告者も「止めればセキュリティ修正が遅れる」と書いています。更新の頻度と許可の取り直しの手間は、トレードオフです。

ほかの手段は、報告では効いていません。ユーザー側のランチャースクリプトはバックグラウンドの経路を覆わず、tccutil reset <サービス> com.anthropic.claude-codeはパス型の行を消さなかったと書かれています。

修正の見通し

#94878は、スペアを含むすべてのプロセスでClaudeCode.appのパスを通し、責任の分離を宣言するよう求めています。2026年10月9日のコメントまで同じ症状の確認が続き、issueはopenのままです。ラベルにはduplicateも付いていて、同じ症状はより古い#49282でも報告されています。

修正が入るまでの現実的な線引きは、次のとおりです。

  • 対話式CLIだけの人は、更新のたびに行が増えることを前提にするか、手動更新に切り替える
  • claude agentsのバックグラウンドセッションで保護フォルダーを読む人は、症状が最も出やすい。更新後の確認を習慣にする
  • LAN内のホストへ接続する人は、ローカルネットワークの許可の一覧を最初に疑う

バックグラウンドセッションの全体像はagent viewの常駐プロセス設計で扱っています。サンドボックスとmacOS固有の権限の関係はsandboxとAppleEventsの記事を参照してください。インストール方式ごとの違いはインストールガイドにあります。

まとめ

更新のたびに許可が消えるのは、TCCがバージョン付きのパスを別のアプリとして扱うためです。署名は変わっておらず、設定の誤りでもありません。v2.1.153以降の説明では許可は残るはずですが、v2.1.293の環境でそうならなかった報告があります。

ログのresponsible_pathで自分の環境が該当するかを確かめ、更新後は現行バージョンの行を有効にして古い行を片付ける。頻度を落とすならDISABLE_AUTOUPDATERで更新の時期を自分で選ぶ。修正が入るまで、できるのはここまでです。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →