Workspace has not been trustedの警告が出る理由と対処(Claude Code)
Claude Codeが「this workspace has not been trusted」と表示してpermissions.allowルールを無視するときの仕組みと、信頼ダイアログを通す対処法をまとめます。
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が承認・拒否を尋ねているわけではありません。承認を求める本体は別にある「ワークスペース信頼ダイアログ」で、このメッセージはそのダイアログをまだ通していないときに、代わりに出る通知にあたります。
denyルールとaskルールはこの警告の対象外です。無視されるのは、ツールの実行を許可する側のallowルールとadditionalDirectoriesだけです。制限を強める設定は信頼の有無にかかわらず常に効きます。実務上の見え方としては、.claude/settings.jsonでBash(npm test)のように個別許可していたコマンドが、信頼前は毎回の承認プロンプトに戻る、という形で気づくことが多いパターンです。
なぜ信頼確認が必要なのか
permissions.allowルールとadditionalDirectoriesは、そのプロジェクトに何を許可するかを決める設定です。リポジトリを他人から受け取った場合、.claude/settings.jsonの中身も一緒に受け取ることになります。そこに書かれた許可ルールを無条件に信じてしまうと、クローンしただけのリポジトリが、確認なしに任意のコマンド実行やディレクトリアクセスを許可してしまいかねません。
この確認の仕組みがワークスペース信頼ダイアログです。対話セッションでプロジェクトディレクトリに入ってclaudeを初めて実行すると、そのフォルダが許可しようとしているルールとディレクトリの一覧を示したうえで、信頼するかどうかを尋ねます。承認すると、以後そのフォルダのallowルールとadditionalDirectoriesが有効になります。同じ確認は初回のコードベース実行だけでなく、プロジェクトが新しいMCPサーバーを.mcp.jsonで持ち込んだときにも別途働きます。
一方で、hooksやenvブロック、apiKeyHelperのようなヘルパーコマンドは信頼を通す前から実行されます。ワークスペース信頼が保留するのは権限を与える側の設定であって、リポジトリが持ち込むコード実行そのものではありません。
信頼はgitリポジトリのルートを単位に保存されます。ただし内側にネストした別のgitリポジトリ(submoduleなど)はこの信頼の対象外で、そこでは改めて確認が必要です。worktreeを使っている場合はメインのチェックアウトのルートが基準です。リポジトリの外でclaudeを起動した場合は、起動したディレクトリを基準に、その配下のサブディレクトリまで信頼が及びます。ただしホームディレクトリで直接claudeを実行した場合だけは例外で、承認してもディスクには保存されず、そのセッション限りの信頼として扱われます。起動のたびにダイアログが出るのはこのためで、保存する設定項目はありません。プロジェクト用のサブディレクトリに移動してから起動するのが実務上の回避策です。
対処法 — 信頼ダイアログを一度通す
対処はメッセージが案内するとおりです。対象のディレクトリで対話セッションを一度開き、ダイアログを承認します。
cd /path/to/project
claude
# ワークスペース信頼ダイアログが表示されたら承認する承認後にセッションを終了しても、信頼はリポジトリルート単位で保存されているため、次回以降は同じ警告が出ません。CI・バッチ処理・SSH経由の自動実行のように対話画面を開けない環境では、ダイアログを一度も出せないため、この手順自体が使えません。その場合はメッセージが示す2つ目の方法で、~/.claude.jsonを直接編集します。
{
"projects": {
"/path/to/project": {
"hasTrustDialogAccepted": true
}
}
}このキーはダイアログでの確認を省略して信頼を与える設定です。内容を確認しないまま許可を与えることになるため、書き込む前に対象ディレクトリの.claude/settings.jsonの中身を見ておくと安全です。
信頼の記録先は各自の~/.claude.jsonであり、リポジトリにコミットされるファイルではありません。同じプロジェクトをチームで共有していても、信頼はメンバーごとに個別で、誰か1人が承認しても他のメンバーには反映されません。新しくプロジェクトに参加したメンバーが同じ警告に遭遇するのは、設定の不備ではなく想定どおりの初回動作です。オンボーディング手順に「初回claude起動時に信頼ダイアログを承認する」という一文を含めておくと、この警告に無駄な時間を使わずに済みます。
「Workspace not trusted」との違い
似た文言にWorkspace not trustedがあります。1字違いですが指している状況が異なるため、混同すると原因を取り違えます。
| メッセージ | 出る場面 | 挙動 |
|---|---|---|
this workspace has not been trusted | 出る場面未信頼のプロジェクトでallowルールやadditionalDirectoriesを読み込もうとしたとき | 挙動該当ルールを無視したまま実行は続く(stderrへの警告) |
Workspace not trusted | 出る場面未信頼のディレクトリでclaude remote-control(Remote Controlのサーバーモード)を起動したとき | 挙動起動そのものを中断する |
前者は「一部の設定が効かないまま動く」、後者は「機能そのものが止まる」という違いがあります。Remote Controlはローカルの実行環境へリモートから接続する機能なので、信頼未確認のまま動かさない安全側の設計です。Remote ControlのケースはWorkspace not trustedエラー — Remote Control起動時の原因と対処で扱っています。
claude -pやAgent SDKではどう見えるか
claude -pのような非対話モードとAgent SDKのセッションは、信頼ダイアログ自体を表示する仕組みを持ちません。未信頼のディレクトリでこれらを実行すると、ダイアログの代わりにこのthis workspace has not been trusted警告がstderrへ出力され、allowルールとadditionalDirectoriesを適用しないまま処理が進みます。対話セッションで信頼済みの親ディレクトリから起動した場合は挙動が異なり、警告の代わりに信頼ダイアログが対象ルールの一覧つきで再表示されます。
自動化パイプラインでclaude -pを使っている場合、この警告が出ていても処理自体は止まりません。ログに埋もれて見落とされやすく、「設定したはずの許可ルールがなぜか効いていない」と後から気づくケースが目立ちます。CI環境でallowルールを確実に効かせたいなら、対話セッションで一度信頼を済ませておくか、hasTrustDialogAcceptedを実行環境の~/.claude.jsonに事前投入しておく必要があります。
.claude/settings.local.jsonが対象になるケース
冒頭の実例のように、対象ファイルとして.claude/settings.local.jsonが表示されることがあります。このファイルは通常、gitignore対象の個人用設定で、信頼確認なしにallowルールが適用されます。ただし次の2条件のどちらかに当てはまると、プロジェクト提供の設定として扱われ、信頼確認の対象になります。
- ファイルがgit管理下に置かれている(誤ってコミットされている場合を含む)
.claudeディレクトリ自体がシンボリックリンクになっている
このケースかどうかを判定するため、Claude Codeは内部でgitコマンドを使います。git判定自体もそのフォルダを信頼して初めて実行されるため、信頼前は「未追跡ファイルとして即座に適用する」設定と「プロジェクト提供として信頼待ちにする」設定のどちらとも決めきれない状態になります。ホームディレクトリ(CLAUDE_CONFIG_DIRで指定した場合を含む)で直接起動したセッションはこの確認自体をスキップし、.claude/settings.local.jsonのルールをそのまま適用する例外があります。
この判定ロジックには古いバージョンでの不具合もありました。v2.1.196からv2.1.199までは、設定ホームやgitリポジトリの外にあるディレクトリでも.claude/settings.local.jsonのルールを保留にしてこの警告を出していました。v2.1.200以降で、設定ホームやリポジトリ外での扱いが現在の仕様に修正されています。さらにv2.1.207より前は、未追跡ファイルのルールを信頼確認より先に適用してしまう逆方向の不具合もありました。同じ症状に見えても、使っているバージョンによって原因の層が違うことがあります。
対象は「プロジェクトが持ち込む設定」だけ
この確認が及ぶのは.claude/settings.jsonと.claude/settings.local.jsonという、プロジェクト側が提供する設定ファイルに限られます。個人用の~/.claude/settings.json(全プロジェクト共通の設定)に書いたallowルールは、この確認の対象に含まれず、信頼ダイアログを経由せずそのまま適用されます。他人のリポジトリを開いたときに警戒すべきなのは、そのリポジトリ自身が持ち込む権限設定であって、自分の端末に元から入っている共通設定まで毎回洗い直す必要はない、という切り分けです。全プロジェクトで同じallowルールを使い回したい場合、プロジェクトごとに信頼を通す代わりに個人設定側へ書いておく方法もあります。
似た仕組みは.mcp.jsonが宣言するheadersHelperにもあります。こちらはMCPサーバーへの認証ヘッダーを生成するシェルコマンドで、信頼が済むまでは実行されず、代わりに静的なheadersだけでサーバーへ接続します。表示される警告文言はheadersHelper not runで、本記事の対象とは別物です。同じ「信頼待ち」という状態が、設定の種類によって別々の警告として現れる一例です。
確実に切り分けるための最小手順
原因の見当がつかないときは、次の順で確認すると早く切り分けられます。
- 出力されたメッセージの対象ファイル名(
.claude/settings.jsonか.claude/settings.local.jsonか)を確認する - 対話セッションで対象ディレクトリに入り
claudeを実行し、ダイアログが出るかを見る - ダイアログが出ないなら、
-pやSDK経由での起動、またはすでに親ディレクトリまでは信頼済みかを疑う - 急いで解消したいだけなら、
~/.claude.jsonのhasTrustDialogAcceptedを直接書く
まとめ
this workspace has not been trustedは、未信頼のプロジェクトでpermissions.allowやadditionalDirectoriesを無視したことを知らせる警告であり、承認を求める対話プロンプトではありません。対話セッションで対象ディレクトリに入りclaudeを一度実行してダイアログを承認するか、対話を開けない環境では~/.claude.jsonのhasTrustDialogAcceptedを直接設定します。同じ「信頼」という言葉を使うWorkspace not trusted(Remote Control起動時のエラー)とは、警告で済むか起動自体が止まるかという点で挙動が異なります。プロジェクトの権限設計全体はClaude Code settings.json完全ガイド、additionalDirectories単体の挙動はadditionalDirectoriesは権限だけ拡張するにまとめています。