Claude Codeでそのworkspaceを信頼してよいか

結論：trustはrepositoryの設定を読む前の入口として判断する

読者の具体的な困りごとは、初回promptを「起動に必要な同意」とだけ考えて押した結果、repositoryに含まれる共有設定や外部接続を後から知り、何を信頼したのか説明できないことです。この記事を読むと、承認、保留、隔離環境での確認を7項目で判断できます。

次の行動：今から開くrepositoryについて、取得元、所有者、確認したcommit、読み込む設定の四つを一行へ記録してください。どれか一つが不明なら、通常端末で承認せずcleanな隔離環境へ切り替えます。

workspace trustが守る範囲と守らない範囲

Anthropic公式Security guideは、初めて扱うcodebaseと新しいMCP serverにtrust verificationがあると説明しています。2026年8月8日のClaude Code v2.1.225では、通常のclaudeと同様のworkspace trust promptがclaude agentsにも追加されました。複数のagentを起動する時も入口を揃える変更です。

trustの承認は、すべてのcommandを自動許可するものではありません。Bash、file編集、network接続はpermission rules、permission mode、sandboxの境界で引き続き判断されます。逆に、permission promptが後で出るからrepository自体は無条件に信頼してよい、という意味でもありません。project scopeのsettings、Hooks、MCP、指示fileはsessionの振る舞いを変えるため、最初に供給元を確認します。

公式Settings guideでは、userが自分で保存した.claude/settings.local.jsonのallow ruleはworkspace trust stepなしで有効になります。ただしrepositoryがそのfileを供給した場合はtrustが適用されます。共有するproject settingsと個人のlocal settingsを混ぜず、誰が配布したruleかを区別することが重要です。

非対話の-pではtrust verificationが無効です。CIでpromptが出ないことを安全確認済みの証拠にせず、checkout元、commit pin、runner隔離、managed settings、credentialのscopeをpipeline側で固定します。対話確認がない実行ほど、事前のprovenance確認を強くします。

承認・保留・隔離確認を6軸で比較する

1. 取得元：自社の正本repositoryと確認済みcommitなら承認候補です。短縮URL、出所不明ZIP、第三者forkは保留します。
2. 変更量：既知のbranchでも大量の未review差分があれば別workspaceとして扱います。特に設定fileだけの変更を見落としません。
3. 設定scope：managedは組織、userは個人、projectは共同、localは端末個人です。repositoryから来るproject設定は共同reviewの対象です。
4. 外部接続：.mcp.json、plugin marketplace、Hooks内のnetwork commandが増える時は、接続先とcredentialを先に確認します。
5. 実行環境：供給元を検証できないが内容確認が必要なら、通常端末で承認せずVM、dev container、権限を絞った一時環境を選びます。
6. 記録：誰が、どのcommitを、何の目的で承認したかを残せない場合は保留します。画面のpromptだけを監査証跡にしません。

承認後も、Claude Codeは作業directoryとそのsubdirectoryを基本のwrite境界とし、外側のpathや追加操作には承認を求めます。ただしread-only Bashや明示allow ruleなど、毎回promptが出ない経路があります。trustとpermissionは二重の安全策であり、片方をもう片方の代用にしません。

初回promptへ答える前の7手順

1. terminalで現在のpathを確認し、ホーム直下やdownload folderではなく対象projectのrootにいることを確認します。
2. repositoryのremote、owner、default branch、現在commitを確認し、自社の正本または意図したforkと一致させます。
3. 未commit差分と新規fileを確認します。vendorから受け取った状態と手元の変更を分離し、設定変更を本文codeに埋もれさせません。
4. CLAUDE.md、.claude/settings.json、.claude/settings.local.json、.mcp.json、plugin定義、Hooksを人間が読みます。
5. permissionのallow・ask・deny、sandboxのread/write/network、Hook eventとcommand、MCPの接続先と認証を一覧にします。
6. 不明な設定があれば通常環境では保留し、networkとsecretを外したVMまたはcontainerで内容を確認します。確認のために本番credentialを渡しません。
7. 承認する場合はrepository、commit、確認者、日時、適用scopeを記録し、最初のtaskをread-onlyの小さな調査に限定します。

ホームディレクトリから直接Claude Codeを起動すると、公式仕様ではtrust acceptanceが現在のsessionだけに保持され、diskへ保存されません。そのため毎回promptが再表示されます。永続化する設定はなく、project subdirectoryから起動するのが正しい切り分けです。繰り返し表示を無理に消すため、ホーム全体を一つのworkspaceとして扱わないでください。

承認後に続ける安全チェックリスト

• project rootから起動した
• remoteとcommitを正本と照合した
• 未commit差分を確認した
• CLAUDE.mdとproject settingsを読んだ
• Hooksのevent・matcher・commandを読んだ
• MCPの接続先とcredential scopeを確認した
• plugin sourceを確認した
• deny・ask・allowを確認した
• sandboxのfilesystemとnetwork境界を確認した
• 最初のtaskをread-onlyにした
• 承認者とcommitを記録した
• 停止・trust再評価の条件を決めた

再評価のtriggerは、remote変更、大規模merge、.claude/・.mcp.json・Hooks・plugin sourceの変更、owner移管、侵害連絡です。一度承認したdirectoryを永久に安全とみなさず、振る舞いを変えるfileのreviewをCODEOWNERSやpull request checklistへ入れます。

workspace trust errorが出た時は、promptを回避するflag探しから始めません。path、所有権、設定fileのread権限、起動面、versionを記録し、同じproject subdirectoryで再現するか確認します。ホーム直下だけで毎回出るなら仕様、知らないprojectで出るなら正常な安全確認、既知projectで急に出るならdirectory識別や設定変更を調べる、と分けます。

よくある質問と次の行動

trust verification、ホーム直下、非対話実行の条件はAnthropic公式Security guide、scopeとlocal settingsの扱いは公式Settings guide、claude agentsへの追加versionはClaude Code公式Changelogで公開直前にも確認してください。

承認後の操作境界はClaude Codeの権限設定、隔離範囲は企業導入checklist、外部serverはMCPセキュリティへつなげます。Miraigentの無料診断では、取得元、settings、Hooks、MCP、permissionを一枚のworkspace受入表へ整理します。