---
title: "Claude Codeのsandboxが1Password SSHエージェントのUnixソケットを塞ぎ署名が失敗する"
description: "Claude Codeのsandboxed Bashから1Password SSH鍵で署名付きコミットを実行すると失敗します。原因はUnixソケット接続の遮断で、sandboxを無効化しなくてもallowUnixSockets設定でソケットパスだけを許可すれば解決します。"
category: "AI"
tags: ["Claude Code","1Password","SSH","Git"]
publishedAt: "2026-07-25"
lastmod: "2026-07-25"
---

Claude Codeのsandboxed Bashから、1PasswordのSSHエージェントで署名する`git commit`を実行すると失敗します。原因はUnixソケットへの接続がsandboxのネットワーク制限で遮断されていることで、sandboxを無効化しなくても`sandbox.network.allowUnixSockets`にエージェントのソケットパスを追加すれば解決します。

```json
{
  "sandbox": {
    "network": {
      "allowUnixSockets": [
        "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"
      ]
    }
  }
}
```

この記事では、原因の切り分け方と、sandboxそのものを外す対処との違いを扱います。

## 症状

`gpg.format=ssh`と1PasswordのSSHエージェントで署名付きコミットをしている環境で、Claude CodeのsandboxedなBashから`git commit`を実行すると次のエラーで失敗します。

```text
error: 1Password: failed to fill whole buffer
fatal: failed to write commit object
```

条件によっては次のエラーになることもあります。

```text
error: 1Password: agent returned an error
```

サブエージェント経由で実行した場合には「account is not signed in」という表示が出ることもありました。1Passwordには実際にサインインしたままだったので、この表示はソケットに到達できないことによる誤表示です。

もっとも分かりやすい手がかりは、同じコマンドをsandboxを無効化した状態で実行すると必ず成功したことでした。1Password側の設定や鍵そのものに問題があるのではなく、sandboxを経由するかどうかだけで結果が変わっています。

## sandboxのネットワーク遮断を疑う

Claude Codeのsandboxed Bashは、[ファイルシステムとネットワークの両方を既定で制限する](https://code.claude.com/docs/en/sandboxing)仕組みです。許可していないドメインへの通信だけでなく、許可していないUnixドメインソケットへの接続も対象になります。1PasswordのSSHエージェントは`~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock`のようなパスにUnixソケットを開いて待ち受けており、`~/.ssh/config`の`IdentityAgent`にこのパスを指定することでgitの署名処理がここに接続します。

sandboxが遮断しているのはファイルの読み書きではなく、このソケットへの接続そのものです。`~/.ssh/config`自体は読めていても、そこに書かれたソケットパスへ実際につなぎに行った時点で拒否されます。エラーメッセージが1Password側の文言のまま出てくるので、最初はSSHの設定ミスや1Password側の不具合に見えますが、実体はsandbox層での遮断でした。

![署名処理の経路。git commitからssh-keygenを経てIdentityAgentのソケットへ接続する段階でsandboxのネットワーク制限に遮断され、1Passwordには届かない](/images/posts/claude-code-sandbox-1password-ssh-signing/where-it-blocks.svg)

## allowUnixSocketsで許可し動作を確認する

冒頭に載せた設定を`settings.json`に追加します。設定を反映したうえで、段階的に動作を確認しました。まず鍵の一覧取得です。

```bash
SSH_AUTH_SOCK="$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock" ssh-add -l
```

エージェント経由で鍵が正しく取得できることを確認したら、次はコミット署名と同じコードパスを直接試します。

```bash
SSH_AUTH_SOCK="$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock" \
  ssh-keygen -Y sign -n git -f ~/.ssh/id_ed25519.pub
```

ここまで成功したのを確認してから、sandboxed Bashのまま実際に`git commit`を実行し、署名が通ることと、コミットオブジェクトの`gpgsig`ヘッダーにSSHシグネチャが正しく埋め込まれていることを確認しました。

## 設定が効かないという報告もある

`allowUnixSockets`は万能ではありません。Claude Codeの公開リポジトリには、同じ設定を書いてもソケットへの接続が「Operation not permitted」で拒否され続けるという[Issue](https://github.com/anthropics/claude-code/issues/16076)があります。ソケットの中継を担う仕組み自体の説明不足を指摘する[別のIssue](https://github.com/anthropics/claude-code/issues/48396)もあり、フォワーダーが何をきっかけに起動するのか、`socat`をユーザー側で叩く必要があるのか、ソケット側にどんな前提条件が要るのかがドキュメント化されておらず、許可リストに登録済みのソケットでも接続できない再現例が添えられています。

手元の環境では設定を反映して即座に解決しましたが、バージョンによって挙動が変わりうる設定だという前提で、反映後は`ssh-add -l`のような軽い確認コマンドで実際につながっているかを確かめてから本番の操作に進むことをおすすめします。

## sandboxを外す選択肢を取らなかった理由

同じ症状を調べると、`git`や`ssh`のコマンドそのものを`excludedCommands`でsandboxの対象から外す、あるいは`allowUnsandboxedCommands`でsandbox化されていない実行を許可する、という対処もよく見かけます。動作はしますが、この対処は該当コマンドについてsandboxの保護をまるごと外します。ネットワークの接続先だけでなく、ファイルシステムへの読み書き制限も一緒になくなるということです。

`allowUnixSockets`なら、そのソケットパス1本だけを許可し、それ以外のファイルアクセスやネットワーク制限はそのまま残せます。1Passwordのエージェントに接続したいだけなら、必要なのはソケット1本の許可であって、`git`や`ssh`を丸ごとsandboxの外に出す理由にはなりません。許可する範囲を絞っておいた分だけ、あとから設定を見直すときに確認する対象も少なくて済みます。

![excludedCommandsとallowUnixSocketsで開く範囲の違い。excludedCommandsはファイルシステムとネットワークの両方の制限をまとめて無効にするが、allowUnixSocketsはソケット1本への経路だけを開き、他の制限は残る](/images/posts/claude-code-sandbox-1password-ssh-signing/scope-of-permission.svg)

ただし、`allowUnixSockets`に登録したソケットなら何でも安全というわけではありません。公式ドキュメントは`/var/run/docker.sock`のような強い権限を持つソケットを例に挙げ、そういったソケットへのアクセスを許可すると結果的にホスト側への抜け道になりうると注意しています。1Passwordのエージェントソケットのように、用途が署名や鍵の取得に限られるものを個別に許可するのと、任意のシステムサービスへの経路を開けてしまうのとでは意味が違います。

## Linux・WSL2での挙動は未確認

ここまでの検証はmacOS上のsandboxed Bashで行っています。Linux・WSL2は[bubblewrap](https://github.com/containers/bubblewrap)でファイルシステムの分離を実装しており、macOSのSeatbeltフレームワークとは別の仕組みです。Unixドメインソケットの遮断を担うのはbubblewrap本体ではなく、任意でインストールする`seccomp`フィルター(`npm install -g @anthropic-ai/sandbox-runtime`)側で、このフィルターが入っていない環境ではソケットの遮断自体が働きません。本文で引いたIssue #48396の再現例もLinux環境(bubblewrapと`socat`)によるもので、`allowUnixSockets`の挙動を確かめる際はseccompフィルターが導入済みかどうかも合わせて確認が必要です。同じ設定キーが同じように機能するかは、macOS以外の環境ではまだ確認できていません。