Workspace not trustedエラー — Remote Control起動時の原因と対処

このTipsでできること

claude remote-control(またはclaude rc)を実行するとError: Workspace not trustedで止まり、コマンドの案内どおりにclaudeを実行しても解決しないことがあります。この記事では、Remote Controlがなぜワークスペースの信頼ダイアログを自分では出せないのか、正しい直し方、ホームディレクトリで実行したときに案内が変わる理由を解説します。

なぜ「Workspace not trusted」が出るか

Claude Codeには、初回のプロジェクトディレクトリでコマンドを実行するときに表示されるワークスペース信頼ダイアログがあります。プロジェクトの.claude/settings.jsonにあるpermissions.allowルールや追加ディレクトリの許可は、このダイアログを承認して初めて有効になります。

信頼ダイアログは対話セッションでのみ表示されます。claude -pや、Remote Controlのサーバーモード(claude remote-control / claude rc)のように、対話画面を開かない起動経路では、このダイアログ自体が出せません。信頼が済んでいないディレクトリでRemote Controlを起動すると、ダイアログを出す代わりにエラーで止まり、先に対話セッションで信頼を済ませるよう案内します。

Error: Workspace not trusted. Please run `claude` in /Users/you/project first to review and accept the workspace trust dialog.

このメッセージが示す直し方は文字どおりで、案内されたディレクトリで通常のclaudeコマンドを実行し、信頼ダイアログが出たら承認します。承認が完了したあとでclaude remote-controlを実行し直すと、今度はサーバーモードが起動します。

cd /Users/you/project
claude
# 信頼ダイアログが出たら承認する。承認後 Ctrl+D や /exit で一度終了してよい
claude remote-control

起動経路によって信頼の扱いが違う

同じ「未信頼のディレクトリ」でも、Claude Codeをどう起動するかで挙動が変わります。対話セッション(claudeをそのまま実行する形)では、信頼が必要になった時点でダイアログが表示され、その場で承認・拒否を選べます。claude -pのような非対話モードでは、このダイアログ自体を表示する仕組みがなく、信頼を確認できないまま実行が進みます。この場合、プロジェクトの.claude/settings.jsonにあるpermissions.allowルールや追加ディレクトリの許可は適用されず、組み込みの既定の権限のまま動作します。

Remote Controlのサーバーモードは、この2つのどちらとも違う挙動を取ります。ダイアログを表示できない点は-pと同じですが、権限ルールを無視してそのまま実行するのではなく、起動そのものを止めてエラーを返します。ローカルのファイルシステムと実行環境にリモートから接続する機能なので、信頼が未確認のディレクトリでは無条件に起動しない、安全側に寄せた設計です。この違いを知っておくと、「-pでは動くのにRemote Controlでは動かない」という状況に遭遇したときの理解が早くなります。

ホームディレクトリで実行したときの特別な案内

案内どおりにclaudeをホームディレクトリで実行しても、この問題は解決しません。ホームディレクトリの信頼は、ダイアログを承認しても保存されない仕様になっているためです。ホームディレクトリでRemote Controlを起動しようとすると、v2.1.214以降は次のような、原因まで踏み込んだ専用メッセージに変わります。

Error: Workspace not trusted. /Users/you is your home directory, and for security home-directory trust is never saved, so running `claude` here first won't help. Run `claude rc` from a project directory instead (run `claude` there once to accept the trust dialog).

対処は「ホームディレクトリではなく、特定のプロジェクトディレクトリに移動してからRemote Controlを起動する」ことです。ホームディレクトリ直下でセッションを始める運用自体を避け、必ず何らかのプロジェクトのルートディレクトリにcdしてからclaude remote-controlを実行します。

v2.1.214より前とどう変わったか

ホームディレクトリでの案内文は、Claude Code v2.1.214で変わりました。

v2.1.213以前は、ホームディレクトリで実行しているケースでも、プロジェクトディレクトリと同じ一般的な文言が表示されていました。案内どおりに同じ場所でclaudeを実行しても信頼が保存されず、堂々巡りになりやすい状態でした。v2.1.214からはホームディレクトリという状況そのものをClaude Codeが検出し、その場で解決しない理由を明示したうえでプロジェクトディレクトリへの移動を促す文言に変わっています。

Remote Controlの前提条件を一緒に確認する

ワークスペースの信頼はRemote Controlが起動しない原因の1つですが、他の前提条件も満たしていないと別のエラーに遭遇します。あわせて確認しておくと切り分けが早くなります。

TeamプランとEnterpriseプランでは、これらに加えて組織のOwnerがClaude Codeの管理設定でRemote Controlのトグルを有効にしている必要があります。既定では無効なので、個人アカウントでは起動できてもチームのアカウントでは別のエラー(組織ポリシーによる無効化)に当たることがあります。これらの前提条件はワークスペースの信頼とは独立に判定されるため、信頼を済ませたあとに別の条件で止まった場合は、順番に1つずつ潰していく形になります。

Remote Controlという機能の広がり

Remote Controlは、ローカルマシンで動いているClaude Codeのセッションに、claude.ai/codeやスマートフォンアプリから接続する仕組みです。コード実行とファイルシステムへのアクセスはローカルマシン側に留まったまま、会話とサブエージェントの進捗を複数の端末で同期できます。クラウドのインフラ上でセッション自体が動く「Claude Code on the web」とは異なり、Remote Controlはあくまでローカルのセッションへの窓という位置づけです。

ローカルの環境がそのまま使えるという性質上、MCPサーバーやプロジェクト固有の設定、@によるファイルパス補完もリモート端末から使えます。ノートPCがスリープしたりネットワークが切れたりしても、復帰時に自動で再接続する設計で、切断中に発生したサブエージェントやワークフローの状態更新は再接続後にまとめて届きます。信頼ダイアログの制約は、この「ローカル環境に直接触れる」という性質と表裏一体です。信頼していないディレクトリでリモートから操作を許してしまうと、ローカルのファイルシステムに対して未確認のコードベースの権限設定がそのまま適用されかねないため、起動前の確認が必須になっています。

この機能は段階的に育ってきた経緯があります。claude remote-controlコマンド自体はv2.1.51で追加され、ブラウザやスマートフォンからのセッション継続はv2.1.79で使えるようになりました。その後の版でも再接続まわりの修正が重ねられており、v2.1.234ではRemote Controlの同期改善が入っています。信頼ダイアログの制約自体は初期から変わっていない設計上の前提で、対話セッションを一度も開いていないマシンやディレクトリでは、Remote Controlだけを単独で使い始めることはできません。

よくある質問

VS Code拡張の/remote-controlでも同じエラーになりますか

VS Code拡張は/remote-controlコマンドで同じ機能を起動しますが、ワークスペースの信頼という前提条件はCLIと共通です。拡張機能側で開いているフォルダが信頼されていなければ、同様に信頼を先に済ませる必要があります。

信頼ダイアログを毎回承認するのが面倒な場合、自動化できますか

対話セッションを経由せずに信頼状態だけを設定したい場合、~/.claude.jsonの該当プロジェクトエントリでhasTrustDialogAcceptedをtrueにする方法があります。ただしこれは信頼ダイアログの表示自体を代替する設定であり、内容を確認せずに信頼を与えることになるため、対象のディレクトリが本当に信頼できるかを踏まえたうえで使う設定です。

claude -pでもワークスペース信頼は必要ですか

claude -pは対話セッションではないため、そもそも信頼ダイアログを表示しません。未信頼のディレクトリでは、プロジェクト設定のpermissions.allowルールなどが適用されない状態のまま実行されます。Remote Controlのようにエラーで止まる挙動とは異なる点に注意が必要です。

一度信頼したディレクトリの配下なら常にRemote Controlを起動できますか

信頼はディレクトリ単位で、信頼した場所の配下のサブディレクトリにも及びます。ただし配下にネストしたgitリポジトリ(別のクローンなど)がある場合は、その内側は別のディレクトリとして扱われ、あらためて信頼が必要になることがあります。モノレポの中で複数のリポジトリを束ねている構成では、Remote Controlを起動するディレクトリがどのリポジトリの範囲に属するかを意識しておくと、思わぬところで信頼エラーに当たらずに済みます。

まとめ

Workspace not trustedは、Remote Controlが信頼ダイアログを自分では表示できないために出るエラーです。エラーメッセージが案内するとおり、対象のプロジェクトディレクトリで一度claudeを実行して信頼ダイアログを承認すれば解決します。ホームディレクトリで実行している場合はこの手順自体が効かないため、必ず特定のプロジェクトディレクトリに移動する必要があります。v2.1.214からはこの2つのケースがメッセージの文言レベルで区別されるようになりました。

同じ「信頼が未確認」という状態でも、対話セッションはダイアログを出し、-pは権限ルールを適用しないまま進み、Remote Controlはエラーで止まるというように、起動経路ごとに挙動が違う点も押さえておく価値があります。サブスクリプション・認証方式・APIエンドポイント・環境変数といった他の前提条件も同時に満たしていないと別のエラーに当たるため、あわせて確認しておくと切り分けが速くなります。