Claude Codeサンドボックスを設定したら、1Password経由のgh/gitが動かなくなった話
はじめに
以前の記事では、Claude Codeのサンドボックスを設定し、ClaudeがBashツール経由で実行するコマンドをOSレベルで安全に制限する方法を紹介しました。
https://dev.classmethod.jp/articles/claude-security-configuration-tips/
しかし、サンドボックスを有効化した影響で、これまで手元で運用していた「1PasswordからGitHubのトークンを取得して gh や git を実行する仕組み」がサンドボックス内でブロックされ、正常に動かなくなってしまいました。
本記事では、なぜ動かなくなったのかと、それぞれの設定を開放した理由・セキュリティ上のトレードオフを解説し、最後に**最終的な設定内容（settings.json）**をまとめます。
前提：検証環境と手元の運用
検証環境
- OS: macOS 26.6.2
- Claude Code: 2.1.285（auto mode、サンドボックス有効、
allowUnsandboxedCommands: false） - 1Password CLI: 2.38.1（デスクトップアプリ連携、GitHub CLI用シェルプラグインを使用）
- GitHub CLI: 2.97.0
手元の運用：gh は裏で 1Password と通信している
普段の開発環境では、GitHubのFine-grained personal access tokenを1Passwordに保管し、ローカル環境には平文で保存しない運用にしています。
その上で1Passwordのシェルプラグインを利用し、~/.zshrc などで gh を次のようなシェル関数としてオーバーライドしていました。
gh() {
op plugin run -- gh "$@"
}
この設定により、gh を呼び出すたびに1Password CLI（op）がデスクトップアプリからトークンを取得し、環境変数 GH_TOKEN（および GITHUB_TOKEN）として本来の gh コマンドに渡して実行されます。
また、git のcredential helperにも op plugin run -- gh auth git-credential を指定しているため、git fetch や git push の認証も同一の経路を経由しています。
なぜ動かなくなったのか？
原因は、gh（の背後で動く op）が行う通信を、サンドボックスが3段階で遮断していたことです。
実際に検証を進めると、1つのブロックを解除するたびに次のフェーズで止まり、エラーが段階的に変化していきました。
| # | 止まった場所 | 主なエラー内容 |
|---|---|---|
| 1 | op → 1Passwordデスクトップアプリ |
アプリへの接続失敗（IPC遮断） |
| 2 | op → 1Passwordサーバー |
ドメインへの通信拒否 |
| 3 | TLS証明書の検証処理（macOS trustd） | x509: OSStatus -26276 |
【補足】
permissions.allowにBash(gh *)を追加しても解決しません
権限ルール（permissions）は「そのコマンドを実行してよいか」を実行前に判定するレイヤーです。一方サンドボックスは「実行されたプロセスがシステムやネットワークの何にアクセスできるか」をOSレベルで制限するレイヤーです。
「受付の顔パスで入室を許可されても、部屋の壁や窓を開ける許可がなければ外部と通信できない」 というイメージです。
つまり、サンドボックス内で gh を正常に動かすには、この3か所の通信経路をサンドボックス側で個別に許可する必要があります。
具体的な設定手順とトレードオフ
設定にあたっては、「安易に excludedCommands でサンドボックスの外に出さない」「必要な通り道だけを1つずつ開け、最小構成を維持する」という方針で進めました。
先ほどの3か所に対して、それぞれ次の設定で通り道を開けていきます。
| # | 止まった場所 | 対応する Claude Code 設定 |
|---|---|---|
| 1 | op → 1Passwordデスクトップアプリ |
sandbox.network.allowMachLookup |
| 2 | op → 1Passwordサーバー |
sandbox.network.allowedDomains |
| 3 | TLS証明書の検証処理（Go / macOS） | sandbox.enableWeakerNetworkIsolation |
1. 1Passwordアプリへのプロセス間通信（Mach IPC）を許可する
op CLIと1Passwordデスクトップアプリは、同一Mac内でのプロセス間通信（IPC）によってやり取りします。デフォルトのサンドボックス環境では、許可されていないIPCはすべて遮断されます。
macOSのIPCには、ファイルパスで接続先を指定する「Unixドメインソケット」と、サービス名で接続先を指定する「Machサービス（XPC）」があります。Claude Codeでは、それぞれ allowUnixSockets と allowMachLookup で個別に許可を設定します。
op バイナリ内の参照文字列を調査したところ、com.1password.browser-helper に関連するMachサービス（例: XXXXXXXXXX.com.1password.browser-helper、先頭の10桁英数字はTeam ID）を利用していることが分かりました。
これを allowMachLookup に追加することで、アプリへの接続が通るようになります。
"allowMachLookup": [
"XXXXXXXXXX.com.1password.browser-helper"
]
補足：Team IDについて
XXXXXXXXXXの部分は、1Passwordの開発元に割り当てられたTeam IDです（本記事ではマスクしています）。1Passwordのグループコンテナパス（~/Library/Group Containers/配下の*.com.1passwordフォルダ名）などから確認できます。
また、グループコンテナ内にはUnixソケットも配置されていますが、手元の検証環境ではallowUnixSocketsで許可しても接続できず、allowMachLookupだけで動作したため、最小権限の原則に従い除外しています。
2. 1Passwordの認証サーバーとGitHubへの通信を許可する
デスクトップアプリへの接続が通ると、次は op が1Passwordのアカウント用サーバー（<チーム名>.1password.com）へ送信する外部ネットワークリクエストが遮断されました。
そこで、サンドボックスの通信許可ドメインに該当ホストを追加します。あわせて gh コマンドが利用する api.github.com と、git fetch や git push が利用する github.com も追加します。
"allowedDomains": [
"<チーム名>.1password.com",
"api.github.com",
"github.com"
]
3. Goツールの証明書検証エラー（trustd）を解消する
外部通信を許可したところ、今度は x509: OSStatus -26276 というTLS証明書エラーが発生しました。
gh や op のようなGo製のCLIツールは、macOS上でTLS証明書を検証する際にOSのデーモンである trustd と通信します。サンドボックスはこの trustd への接続も遮断してしまうため、証明書の検証に失敗してしまいます。
この問題の対処法としては以下の3つが考えられます。
| 選択肢 | 内容 | 残る守り |
|---|---|---|
excludedCommands（公式推奨） |
gh をサンドボックスの外で動かす |
gh 実行中はファイル制限・通信制限ともに失われる |
enableWeakerNetworkIsolation |
サンドボックス内から trustd への接続を許可する |
ファイル読み書きの制限は維持される（ただし、サンドボックス内のすべてのコマンドで通信の分離が一部弱まる） |
! プレフィックスで手動実行 |
Claudeには実行させず、ユーザーが都度手動実行する | サンドボックスの制限は最大（ただし自動化の利便性は低下） |
今回は「Claudeによるファイルの不要な読み取り・意図しない書き込みを防ぐ」というサンドボックス本来の恩恵を残すため、公式の推奨（excludedCommands）ではなく enableWeakerNetworkIsolation: true を採用しました。
"enableWeakerNetworkIsolation": true
リスクと許容理由
公式ドキュメントでは、この設定を有効にすると trustd を通じた潜在的なデータ持ち出し経路が開くため、セキュリティが低下すると説明されています。
具体的な仕組みまでは公式に説明されていませんが、私の理解では、悪意のあるコードが細工された証明書を trustd に検証させることで、許可外のURLへリクエストを飛ばし、そのURLに情報を乗せて持ち出すといったケースが考えられます。
しかし、これは「すでにサンドボックス内で悪意のあるコードが実行されている」ことが前提のリスクです。ファイル制限やその他の通信制限は引き続き有効に機能するため、コマンド全体をサンドボックス外に追い出す excludedCommands と比較すれば十分に小さく、許容できるリスクであると判断しました。
- 参考：Claude Code 設定リファレンス (sandbox.enableWeakerNetworkIsolation)
- 参考：サンドボックス化された Bash ツールを設定する (トラブルシューティング)
4. 防護策：Claudeによる op の直接実行を拒否する
1Passwordへの通信経路を開放したことで、「Claudeが直接 op item get などを実行して保管庫内の他のシークレットを読み取ってしまう」という懸念が生じます。
そこで安全のための防護策として、permissions.deny に Bash(op *) を明示的に指定し、Claudeからの直接呼び出しを禁止します。
"permissions": {
"deny": [
"Bash(op *)"
]
}
Claude Codeの権限ルールは「Claude自身が発行したコマンド文字列」を基準に評価されます。そのため、シェル関数である gh の内部から自動で呼び出される op コマンドがブロックされることはありません。
補足：この拒否ルールは完全な壁ではありません
権限ルールはコマンド文字列で判定するため、スクリプトの中から間接的にopを呼び出すといった抜け道までは防げません。公式ドキュメントでも、Bashの拒否ルールはセキュリティ境界として完全ではないと説明されています。最終的な歯止めは、1Passwordデスクトップアプリ側での承認になります。
最終的な設定（settings.json）
ここまでの要件をまとめた設定ファイルは以下のとおりです。~/.claude/settings.json に設定を追加・反映します。
{
"permissions": {
"deny": [
// 防護策：Claudeが直接 op コマンドを実行して情報を抜き取るのを防ぐ
"Bash(op *)"
]
},
"sandbox": {
"enabled": true,
"allowUnsandboxedCommands": false,
// 3. Go製CLI（gh / op）のTLS証明書検証エラー（trustd通信）を解消
"enableWeakerNetworkIsolation": true,
"network": {
// 2. 1PasswordとGitHubの必要な通信先のみを許可
"allowedDomains": [
"<チーム名>.1password.com",
"api.github.com",
"github.com"
],
// 1. 1Passwordデスクトップアプリへのプロセス間通信（Machサービス）を許可
"allowMachLookup": [
"XXXXXXXXXX.com.1password.browser-helper"
]
}
}
}
この設定により、以下のセキュリティ強度を維持しながら gh や git をClaudeに実行させることができます。
- サンドボックスの維持：Claudeが実行するコマンドは例外なくサンドボックス内に閉じ込められ、ファイルシステムの保護が機能し続ける
- 安全なシークレット管理：GitHubトークンをローカルに平文保存せず、1Passwordの一元管理を維持できる
- 最小特権の通信：開放する通信経路は「特定のMachサービス1件」「OSのtrustd」「必要ドメイン3件」のみに限定される
おわりに
Claude Codeのサンドボックスは安全性を大きく高めてくれる強力な機能ですが、ローカルアプリと連携するCLIツールを運用している場合は予期せぬ通信遮断に遭遇することがあります。
動かないからといってサンドボックスを丸ごと無効化したり、安易に例外コマンド（excludedCommands）へ逃がすのではなく、遮断されているプロセス間通信やネットワーク通信を1つずつ特定して許可していくことで、堅牢性を保ったまま利便性を回復できました。
「Claude Codeのサンドボックスをしっかり効かせつつ、1Password × GitHub CLIの運用も崩したくない」という方の参考になれば幸いです。
