【続・cage】allow-keychain を外したら Claude Code にログインできなくなった話と、その解決策

2026年3月7日

cage で Claude Code をサンドボックス化したのはいいものの、「あれ、ログインできない……」となったこと、ありませんか？

前回の記事（Claude Code を安全に「自走」させたい人へ。cage で囲む方法を、つまずきながら書きました）では、cage のインストールから設定、ダンマリ問題の解決までをお伝えしました。

あの記事では allow-keychain を外す方針で書きました。「キーチェーンには他のサービスのパスワードも入っているし、Claude Code に触らせたくない」と。必要なときは claude-raw で cage なし起動すればいいやん、と。

ところが、実際に運用してみると……これがうまくいかなかったんです。

結論からお伝えすると、allow-keychain: true は付けておいた方がいいです。外すと cage 経由での起動のたびに認証を求められ、しかもその認証自体が通りません。

何が起きたか

cage の設定で allow-keychain を外した状態で cage claude を実行すると、Google 認証の画面が開きます。

ふだんなら認証済みなのでそのまま使えるはずなのに、ローディングがぐるぐる回ったまま進まない。

どうしよう。

切り分けてみた

まず cage が原因かどうかを確認しました。

claude-raw（cage なし）で起動 → 認証不要でそのまま使える
cage claude（cage あり）で起動 → 認証を求められ、Google の画面で止まる

cage が原因です。で、さらに絞り込みます。

cage -allow-all claude → 動く
allow-keychain: true を付けて cage claude → 動く
allow-keychain を外して cage claude → 止まる

allow-keychain が犯人でした。

なぜキーチェーンが必要なのか

macOS のキーチェーンは、通常のファイル読み書きとは別の仕組みで動いています。

Claude Code は認証情報をキーチェーンに保存しています。cage の allow-keychain がないと、保存済みの認証情報の読み取りすらできないんです。

だから毎回ログインを求められる。しかもそのログイン処理自体もキーチェーンへの書き込みが必要なので、認証が永遠に完了しない。

なんでやねん……いや、仕組みを考えれば当然なんですが。

allow-keychain: true にしても大丈夫？

ドキドキしますよね。キーチェーンには 1Password や Gmail、いろんなサービスの認証情報が入っています。

ただ、macOS のキーチェーンにはアプリケーションごとのアクセス制御があります。

Claude Code がキーチェーンに書くのは 自分の認証情報だけ
他のアプリケーションが保存した項目を読み取ろうとすると、macOS のセキュリティプロンプトが別途表示される
つまり、気づかないうちにパスワードを抜かれるということはない

allow-keychain: true は「キーチェーンの仕組み自体へのアクセスを許可する」であって、「全パスワードを自由に読める」ではない、という感じです。

ほっ。

設定の修正

前回の記事で紹介した presets.yaml に allow-keychain: true を追加します。

presets:
  claude-code:
    allow:
      - "."
      - path: "/tmp"
        eval-symlinks: true
      - "$HOME/.npm"
      - "$HOME/.npm-global"
      - "$HOME/.claude"
      - "$HOME/.claude.json"
      - "$HOME/.config/claude"
      - "/dev/tty"
      - "/dev/ttys*"
    allow-keychain: true

auto-presets:
  - command: claude
    presets:
      - claude-code

変更したのは allow-keychain: true の1行だけです。

設定ファイルの場所はここです。

nano "$HOME/Library/Application Support/cage/presets.yaml"

保存したら、すぐに反映されます。cage の再起動などは不要です。

修正後の動作確認

cage claude

認証を求められずに、すぐに使えるようになりました。ふぅ。

claude --continue や claude -p "テストを実行して" も問題なく動きます。

セキュリティ方針の見直し

前回の記事では「まず最小限にして、必要になったら追加する」と書きました。その方針自体は変わりません。

ただ、allow-keychain については「外すと実用にならない」ということがわかりました。運用してみないとわからないこと、ありますよね。

見直し後の方針をまとめます。

設定	判断	理由
`allow-keychain: true`	必須	外すと認証できない。macOS のアクセス制御で他アプリの情報は守られる
`$HOME/.cache`	不要	範囲が広すぎる。必要なら個別に追加
`$HOME/.local`	不要	同上

「まず最小限」の原則は維持しつつ、キーチェーンだけは最初から許可しておくのがおすすめです。

cage のトラブルシューティングのコツ

前回の記事でもお伝えしましたが、cage で問題が起きたときの鉄板の対処法を改めて書いておきます。

1. まず cage が原因か切り分ける

command claude  # cage を通さず直接起動

これで動くなら cage が原因です。

2. 制限を全部外して試す

cage -allow-all claude --dangerously-skip-permissions

これで動くなら、書き込み制限のどれかが引っかかっています。

3. macOS のログで拒否されたパスを特定する

log stream --predicate 'eventMessage contains "deny" and eventMessage contains "file-write"' --style compact

別のターミナルで claude を起動して、ログに流れてくる deny の行を見ます。ブロックされているパスが特定できます。

この3ステップで、cage のほとんどの問題は解決できます。

まとめ

前回の記事で allow-keychain を外す方針を書きましたが、実際に運用してみると認証が通らなくなることがわかりました。

allow-keychain: true は付けておく — 外すと cage 経由で Claude Code にログインできなくなる
macOS のキーチェーンにはアプリ単位のアクセス制御がある — 他のパスワードが勝手に読まれることはない
トラブル時は log stream で切り分け — cage はエラーを出さないので、OS ログが頼り

cage + hooks + settings.json の3層防御については、前回の記事を参照してください。

→ cage で囲む方法を、つまずきながら書きました

→ Claude Code Guard（GitHub）

お試しください。