Workspace has not been trustedの警告が出る理由と対処(Claude Code)

this workspace has not been trusted は、プロジェクトの.claude/settings.jsonに書いたpermissions.allowルールやadditionalDirectoriesが無視されているときに出るメッセージです。対話画面で許可を求める質問ではなく、権限ルールを適用しなかったことを知らせる警告で、意味を取り違えると「設定が壊れた」と誤解しがちです。出る条件、対処、そして警告が出ている裏で何が動いているかを順に見ます。

「質問」ではなく「適用しなかった」という報告

このメッセージは次の形で出ます。

Ignoring 2 permissions.allow entries from .claude/settings.local.json: this workspace has not been trusted. Run Claude Code interactively here once and accept the trust dialog, or set projects["/Users/you/project"].hasTrustDialogAccepted: true in /Users/you/.claude.json.

件数(2)・対象ファイル名(.claude/settings.local.jsonなど)・プロジェクトパスは設定内容によって変わります。読み取れるのは1点だけです。プロジェクト設定のallowルールがこのセッションでは適用されなかったという事実で、Claude Codeが承認・拒否を尋ねているわけではありません。承認を求める本体は別にある「ワークスペース信頼ダイアログ」で、このメッセージはそのダイアログをまだ通していないときに、代わりに出る通知にあたります。

なぜ信頼確認が必要なのか

リポジトリを他人から受け取ると、.claude/settings.jsonの中身も一緒に受け取ります。そこに書かれた許可ルールを無条件に信じると、クローンしただけのリポジトリが、確認なしに任意のコマンド実行やディレクトリアクセスを許可してしまいかねません。

この確認の仕組みがワークスペース信頼ダイアログです。対話セッションでプロジェクトディレクトリに入ってclaudeを初めて実行すると、そのフォルダが許可しようとしているルールとディレクトリの一覧を示したうえで、信頼するかどうかを尋ねます。承認すると、以後そのフォルダのallowルールとadditionalDirectoriesが有効になります。同じ確認は、プロジェクトが.mcp.jsonで新しいMCPサーバーを持ち込んだときにも別途働きます。

警告の裏で動いているもの — 信頼前の実行範囲

警告が出ているのはallowルールが止まっているからで、リポジトリが持ち込むものがすべて止まっているわけではありません。特に、警告が出やすいclaude -pやAgent SDKでは、フックなどが動いたままです。

自分で書いていないリポジトリでclaude -pを回すときは、何を動かしてよいかを先に決められます。--setting-sources userを付けると、プロジェクトの設定ファイルと.mcp.jsonのどちらも読みません。--bareならフック・skill・サブエージェント・プラグイン・.mcp.jsonのサーバーを読みません。ただしプロジェクトのenvブロックとawsAuthRefreshなどのヘルパーは残り、apiKeyHelperは--settingsからだけ読みます。.mcp.jsonの特定のサーバーだけ避けるなら、設定のdisabledMcpjsonServersに名前を書きます。どのセッション種別でも、そのサーバーは拒否されます。フックだけ止めるなら、--settings '{"disableAllHooks": true}'を渡します。ユーザー設定に書くだけでは足りません。プロジェクト設定のほうが優先されるため、リポジトリ側でfalseに戻せるからです。

信頼は何を単位に保存されるか

保存の単位は、claudeをどこで起動したかで変わります。

ホームディレクトリで直接claudeを実行した場合だけは例外です。承認してもディスクには保存されず、そのセッション限りの信頼になります。起動のたびにダイアログが出るのはこのためで、保存する設定項目はありません。プロジェクト用のサブディレクトリに移動してから起動すると、その場所の信頼が保存されます。

対処法 — 信頼ダイアログを一度通す

対象のディレクトリで対話セッションを一度開き、ダイアログを承認します。

cd /path/to/project
claude
# ワークスペース信頼ダイアログが表示されたら承認する

承認後にセッションを終了しても、信頼はルート単位で保存されているため、次回以降は同じ警告が出ません。CI・バッチ処理・SSH経由の自動実行のように対話画面を開けない環境では、この手順が使えません。その場合は、~/.claude.jsonを直接編集します。キーはメッセージの末尾に表示されるものをそのまま使います。

{
  "projects": {
    "/path/to/project": {
      "hasTrustDialogAccepted": true
    }
  }
}

このキーは、ダイアログでの確認を省略して信頼を与える設定です。書き込む前に、対象ディレクトリの.claude/settings.jsonの中身を見ておくと安全です。リポジトリの外なら、<path>にはそのフォルダ自身を書きます。

信頼の記録先は各自の~/.claude.jsonで、リポジトリにコミットされるファイルではありません。同じプロジェクトをチームで共有していても、信頼はメンバーごとに個別です。誰か1人が承認しても他のメンバーには反映されず、新しく参加したメンバーの初回起動で信頼ダイアログが出るのは想定どおりの動作です(-pやスクリプトから先に使うと、この警告になります)。オンボーディング手順に「初回claude起動時に信頼ダイアログを承認する」と1行入れておくと、この警告に時間を使わずに済みます。

「Workspace not trusted」との違い

似た文言にWorkspace not trustedがあります。1字違いですが、指している状況が異なります。

前者は「一部の設定が効かないまま動く」、後の2つは「機能そのものが止まる」という違いです。後の2つが止まるのは、ダイアログを出せない場面です。たとえば標準入力か標準出力がターミナルでないとき、ターミナルが小さすぎるとき、スクリプトから呼んだときが当たります。同じディレクトリでターミナルから実行すれば、止まる代わりにダイアログが表示されます(Remote Controlはv2.1.284以降。ホームディレクトリでは承認しても通りません)。Remote ControlのケースはWorkspace not trustedエラー — Remote Control起動時の原因と対処で扱っています。

claude -pやAgent SDKではどう見えるか

claude -pのような非対話モードとAgent SDKのセッションは、信頼ダイアログを表示しません。親フォルダを信頼済みでも、-pとSDKでは数えません。

v2.1.285のclaude --helpの-pの説明は、この扱いをさらに広く書いています。

-p, --print    Print response and exit (useful for pipes). Note: The workspace
               trust dialog is skipped when Claude is run in non-interactive
               mode (via -p, or when stdout is not a TTY, e.g. piped or
               redirected output). Only use this in directories you trust.

-pを付けなくても、標準出力をパイプやリダイレクトに向けるとダイアログは出ません。claude | tee session.logのような起動は、対話画面を開いているつもりでも非対話モードと同じ扱いです。

設定したはずの許可ルールが効いていないと、後から気づくことになります。CI環境でallowルールを効かせたいなら、対話セッションで一度信頼を済ませておくか、hasTrustDialogAcceptedを実行環境の~/.claude.jsonに事前投入します。

.claude/settings.local.jsonが対象になるケース

冒頭の実例のように、対象ファイルとして.claude/settings.local.jsonが表示されることがあります。このファイルは通常、gitignore対象の個人用設定で、信頼確認なしにallowルールが適用されます。ただし次のどちらかに当てはまると、プロジェクト提供の設定として扱われ、信頼確認の対象になります。

• ファイルがgit管理下に置かれている(誤ってコミットされている場合を含む)
• .claudeディレクトリ自体がシンボリックリンクになっている

この判定にClaude Codeはgitを使い、しかもgitを走らせるのは、そのフォルダ(または信頼が及ぶ親フォルダ)を信頼したあとです。-pとSDKのセッションは承認済みとして数えるため、未追跡のルールも適用されます。信頼前のルールの扱いは、起動した場所で決まります。

• 設定ホーム(ホームディレクトリ、またはCLAUDE_CONFIG_DIRに指定した.claudeディレクトリの親): gitを走らせず、ルールをすぐ適用する。ただしCLAUDE_CONFIG_DIRのディレクトリがgitリポジトリの中にあり、ローカル設定をリポジトリルートに置く構成なら、他と同じく保留にする
• それ以外: プロジェクト設定と同じく保留にする。判定が済んだあとは、未追跡のファイルやgitリポジトリ外のファイルのルールを、そのフォルダを信頼していなくても適用する

設定ホームの例外が飛ばすのは信頼の確認だけです。~/.claude/settings.local.jsonはローカルスコープのままなので、ホームディレクトリで起動したセッションでしか読まれません。全プロジェクトで使い回したい許可ルールは、ユーザー設定の~/.claude/settings.json(CLAUDE_CONFIG_DIRを設定していればその配下のsettings.json)に書きます。

同じ症状に見えても、使っているバージョンによって原因の層が違うことがあります。

対象は「プロジェクトが持ち込む設定」だけ

この確認が及ぶのは、.claude/settings.jsonと.claude/settings.local.jsonというプロジェクト側の設定ファイルです。個人用の~/.claude/settings.jsonに書いたallowルールは、信頼ダイアログを経由せずそのまま適用されます。他人のリポジトリで気にするのは、そのリポジトリが持ち込む権限設定であって、自分の端末に元からある共通設定まで洗い直す必要はない、という切り分けです。

似た仕組みは.mcp.jsonが宣言するheadersHelperにもあります。MCPサーバーへの認証ヘッダーを生成するシェルコマンドで、信頼が済むまでは実行されず、静的なheadersだけで接続します。claude -pでは、サーバーごとにheadersHelper not runという行がstderrに出ます。v2.1.238より前は、claude -pでも親フォルダだけを信頼した場合でも実行されていました。

警告の原因を切り分ける順序

原因の見当がつかないときは、次の順で確認します。

v2.1.285で確認した、信頼まわりのコマンド出力

信頼に関わるコマンドのうち、ログインもモデル呼び出しもせずに画面へ出せるものを、v2.1.285で実行しました。claude doctorはclaude --helpのコマンド一覧に、次のように載っています。

doctor    Check the health of your Claude Code installation. Reads settings
          files in the current directory without a trust prompt. For a full
          checkup that can also fix issues, run /doctor in a session.

claude doctorは信頼プロンプトを出さずにカレントディレクトリの設定ファイルを読むので、他人のリポジトリで実行する前に頭に置いておきたい挙動です。同じ--helpには、プロジェクト・ユーザー・ローカルの設定ファイルをすべて無視する--restrictedもあります。組み込みのBash・PowerShellなどコード実行系のツールとWebFetchを外し、ファイル操作を作業ディレクトリに閉じます。--toolsで名前を挙げたツールは残ります。

ログインしていない状態でclaude remote-controlを起動すると、信頼の前に認証で止まります。

$ claude remote-control --help
Error: You must be logged in to use Remote Control.
 
Remote Control is only available with claude.ai subscriptions. Run `claude auth login` to sign in with your claude.ai account.

この段階では信頼の確認まで進まないので、Workspace not trustedの文言は再現できませんでした。

まとめ

警告が出たら、まず対話で起動したのか、-p・パイプ経由なのかを見ます。前者ならダイアログを通せば済み、後者なら「何を動かしてよいか」を先に決める問題になります。プロジェクトの権限設計全体はClaude Code settings.json完全ガイド、additionalDirectories単体の挙動はadditionalDirectoriesは権限だけ拡張するにあります。