1Password CLIのTerminal認証連携がClaude Codeで機能しないのでToken経由にて対策をとってみた
手元の環境でClaude Code 上から 1Password CLI（以下 CLI）を呼び出すと、Touch ID の利用回数が極端に多くなっていました。現象を整理してみると、以下の通りとなります。
- ターミナルから直接 CLI を実行したケースでは「Integrate with 1Password CLI」が機能し、2回目以降は Touch ID を求められない
- Claude Code 上から CLI を実行したケースでは、毎回 Touch ID プロンプトが表示される
Claude Code 上では CLI の連携設定が機能していないように見えました。対処方法としては、最新版の 1Password には Settings → Developer 配下に再認証間隔を延長するオプションがあるようですが、手元のバージョンにはこの設定項目が存在しませんでした。
今回は、CLIに用意された環境変数を利用しつつ、「Integrate with 1Password CLI」オプションには頼らない形で解決した手順について解説します。
前提環境
| 項目 | バージョン |
|---|---|
| macOS | Sequoia 15.3 |
| 1Password デスクトップアプリ | 8.12.12（再認証間隔の延長設定なし） |
CLI（op） |
2.32.0 |
| direnv | 2.37.1 |
| シェル | zsh |
オプションの動作検証
「Integrate with 1Password CLI」を有効にしてターミナル上でCLIを呼んだ場合、1回目はTouch ID ダイアログがでますが、2回目以降直ぐには表示されません。これはダイアログ内のトグル通りの動作となります。
次に、Claude Code 上で CLI を呼んで認証し、直ぐでも暫く時間をおいたとしても再度呼ぶと都度 Touch ID ダイアログがでる状況でした。これはダイアログ内のトグルを開くと矛盾した動作であることが認知できます。
試しにオプション設定をオフにすると以下のエラーで弾かれます。
You are not currently signed in
「Integrate with 1Password CLI」を有効にして、ターミナル上でCLIを呼んでTouch ID ダイアログを認証した上で Claude Code を実行します。Claude Code上でCLIを呼び出す度に Touch ID ダイアログが表示されました。
原因
1Password app は op の呼び出し元プロセスを peer entitlement で識別しており、Touch ID 承認はそのプロセス（の系譜）に紐付きます。Terminalで承認した認証セッションは、Terminal とは別プロセスツリーで起動した Claude Code から呼ばれた op には引き継がれない、というのが原因のようです。これは Claude Code に推測してもらった結果となります。
対策
CLI には OP_SESSION_<shorthand> という環境変数が用意されており、ここにセッショントークンを設定することでサブプロセスでも CLI の認証を引き継げるようになります。トークン自体は連携を切った状態で op signin --raw を実行すると標準出力に表示されます。詳細は公式ドキュメントを参照。
OP_SESSION_<shorthand> のトークンは概ね 30 分の操作なし、または最大12時間で失効します。
今回は、プロジェクトディレクトリに cd した時点でセッショントークンの設定を自動発火できるようにしてみます。
direnv と組み合わせます。.envrc は direnv が bash で実行する仕様のため、zsh 構文を含む opsi をそのまま書くことはできませんが、direnv_load で zsh サブプロセスを噛ませれば回避できます。
# ~/.config/shell/opsi.zsh
opsi() {
local account="<your-account-shorthand>" # op account list で確認
local var="OP_SESSION_${account}"
if [[ -n "${(P)var}" ]] && op account get --account "$account" >/dev/null 2>&1; then
return 0
fi
local token
token="$(op signin --account "$account" --raw)" || return 1
[[ -z "$token" ]] && return 1
export "$var=$token"
}
# ~/.zshrc
eval "$(direnv hook zsh)"
source ~/.config/shell/opsi.zsh
# .envrc
direnv_load zsh -c 'source ~/.config/shell/opsi.zsh && opsi && direnv dump'
direnv allow を忘れずに実行します。
なお direnv_load は標準出力を direnv dump 形式として解釈するため、opsi 内に echo 等のデバッグ出力を含めるとパースが壊れます。デバッグ出力は stderr に流しましょう。
注意点
OP_SESSION_<shorthand>を.zshenv等で永続化してはいけない（メモリ上のみで保持する）- CI / バッチ / 共有サーバでの完全非対話自動化には、Service Account Token（
OP_SERVICE_ACCOUNT_TOKEN）をdirenvで局所注入する方式が本筋 - Service Account には vault のスコープを明示付与する必要があり、共有 vault には別途権限設定が必要
OP_SESSION_<shorthand>環境変数によるセッション保持は、Gemini からの提案を起点に CLI の挙動として実機確認したものです。現状は動作していますが、将来の仕様変更で動かなくなる可能性があるため、本記事の方法は自己責任で利用してください。
あとがき
今回の手続きにて、CLIの認証がセッションあたり1回で済むようになります。セキュリティ面では、Touch ID プロンプトが頻発する状態に慣れると不審なプロンプトでも反射的に承認しがちですが、本手法でプロンプト頻度を下げることで想定外のプロンプトに気付きやすくなります。
ただ、OP_SESSION_* がプロセスメモリに残る間は CLI認証が通るので、シェル環境への侵入があれば再認証なしで読み取られる可能性があります。
アプリケーションの設定次第では不要な手続きですが、万が一該当した時の参考になれば幸いです。
参考リンク：
1Password CLI signin documentation
1Password Service Accounts
