one-password について
1Password CLIによる認証情報の取り扱いを案内するスキルです。サービスアカウントでのアクセス、同意を得たデスクトップアクセス、リリース用シークレットの管理手順を定めています。
主な機能
- 01サービスアカウントのアクセス手順
- 02デスクトップアクセス時の同意確認
- 03認証情報の検索とフィールド案内
- 04リリース用認証情報の整理
- 05共有 tmux タスクワークフロー
活用シーン
- 01Moltyボルトからの認証情報取得
- 02同意のもとでのMolty外の認証情報処理
- 03リポジトリ向けリリースシークレットの確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ steipete/ agent-scripts --skill one-passwordインストール後、Claude Code で/one-passwordを入力して読み込まれたか確認します。
同梱ファイルreferences/cli-examples.mdreferences/get-started.md
詳細
1Password CLI
インストール(安定したパスのみ — brew は使用しないでください)
Peter のすべての Mac で op は ~/bin/op にあり、互換性のためのシンボリックリンク /opt/homebrew/bin/op -> ~/bin/op も設定されています。Homebrew cask を使ってインストール/アップグレードしないでください。バージョンごとに変わる Caskroom のパスを使うと、アップグレードのたびに op の macOS TCC ID が新しくなり、Peter に「App Data Protection」のダイアログが再度表示されます。更新するには、https://app-updates.agilebits.com/product_history/CLI2 から公式署名済みパッケージをダウンロードし、pkgutil --check-signature(AgileBits 2BUA8C4S2C)と pkgutil --expand-full を実行してから、install -m 755 <payload>/op ~/bin/op を実行します。パスを固定することで、パス/バージョンによる ID の変動は防げますが、op プロセスをまたいで macOS の許可が維持されるわけではありません。
その他の手順については、公式の CLI スタートガイドに従ってください。インストールコマンドを推測しないでください。
参考資料
- 公式ドキュメント:https://developer.1password.com/docs/cli/get-started/
- 公式アプリ連携設定:https://developer.1password.com/docs/cli/app-integration/
- Apple の
SystemPolicyAppData:https://developer.apple.com/documentation/xcode/resetting-access-to-protected-resources-in-macos - 繰り返しダイアログが表示される既知のバグ:https://github.com/1Password/shell-plugins/issues/586
references/get-started.md(インストール+アプリ連携+サインインの手順)references/cli-examples.md(安全なアイテム作成/編集パターンを含む、実際のopの例)
アクセス方法(順序厳守)
1. サービスアカウント — デフォルト、プロンプトなし。 OP_SERVICE_ACCOUNT_TOKEN は ~/.profile(Codex が管理するブロック)からエクスポートされており、Molty ボルト(読み取り+書き込み)にスコープされています。サービスアカウントのコマンドでは、必ず OP_LOAD_DESKTOP_APP_SETTINGS=false と OP_BIOMETRIC_UNLOCK_ENABLED=false の両方を設定してください。前者は設定ファイルの読み込みを防ぎ、後者は 1Password 公式のアプリ連携オーバーライドです。
- 必須のコマンド形式:
OP_LOAD_DESKTOP_APP_SETTINGS=false OP_BIOMETRIC_UNLOCK_ENABLED=false OP_SERVICE_ACCOUNT_TOKEN="$OP_SERVICE_ACCOUNT_TOKEN" op item get "<item>" --vault Molty ...。 --vault Moltyは必須です。有効なトークンがあっても、省略すると失敗します。- この方法では、
op signinを絶対に実行しないでください。また、--accountも絶対に指定しないでください。どちらもデスクトップアプリ経由になり、Peter に「Authorize」プロンプトが表示されます。--accountとトークンの併用は常に誤りで、対話型の方法に切り替わります。 - 旧エイリアスの
MOLTY_OP_SERVICE_ACCOUNT_TOKENはフォールバック専用です。古い可能性があります。 - トークンがない/期限切れ、またはアイテムの読み取りに失敗した場合は、正確なエラーを報告して確認を求めてください。デスクトップアプリに黙ってフォールバックしないでください。
2. デスクトップアプリ — 明示的な同意がある場合のみ。 Molty の対象外に実際にあるアイテム(個人用の Private ボルト、OpenClaw-Core)に使用します。自動的にフォールバックしないでください。
- まずチャットで作業を止めて、アイテム名と必要な理由を伝えてください。承認を待ちます。
- プライマリではないホスト、VM、またはヘッドレスホストでは、この方法を対応する個人用または業務管理対象の環境にあるアクティブな物理ワークステーションにルーティングしてください。「リモートルーティング — デスクトップ経路のみ」を参照してください。
- 承認後は、共有
op-workセッション内で作業用のウィンドウを1つ使用します(以下を参照)。そのウィンドウ内で、まずunset OP_SERVICE_ACCOUNT_TOKEN MOLTY_OP_SERVICE_ACCOUNT_TOKENを実行してください。エクスポート済みのサービスアカウントトークンは--account my.1password.comより優先され、読み取り先を黙って Molty に限定するためです。次にop signin --account my.1password.comを1回実行し、タスク全体の対話型読み取りをすべて同じウィンドウにまとめ、可能であれば1回のop run/op inject呼び出しにまとめてください。TTY を再利用すると 1Password の「Authorize」プロンプトを減らせますが、新しいopPID でも別個の macOS App Data 許可が維持されるわけではありません。 - ネームプレートや sag の事前通知は不要です。Peter がチャットでロック解除を承認した後、1Password のプロンプトに応答がない場合に限り、音声通知(
sag)を行ってください。
既知の Molty 項目(検索をスキップ)
正確なタイトルを指定し、そのままサービスアカウントの読み取りに進んでください。一覧表示は不要です。
| 目的 | 項目タイトル | フィールド |
|---|---|---|
| OpenAI(OpenClaw/i18n ジョブ) | AI API Key - OpenAI - OPENAI_API_KEY - OpenClaw | OPENAI_API_KEY |
| OpenAI(Serviceable Access) | AI API Key - OpenAI - OPENAI_API_KEY - Serviceable Access | OPENAI_API_KEY |
| Anthropic(ライブテスト) | AI API Key - Anthropic - ANTHROPIC_API_KEY - OpenClaw Live Tests | ANTHROPIC_API_KEY |
| Anthropic(clawdbot) | AI API Key - Anthropic - ANTHROPIC_API_KEY - Clawdbot | ANTHROPIC_API_KEY |
| Gemini | AI API Key - Google Gemini - GEMINI_API_KEY - steipete-m5 | GEMINI_API_KEY |
| App Store Connect リリース | API Key - App Store Connect - Personal - Release | private_key_p8、key_id、issuer_id |
| npm リリース自動化 | npm Registry - steipete - Release Automation | $npm を参照 |
| Cloudflare(OpenClaw サービス) | OpenClaw Services Cloudflare API Token | credential |
| Sparkle 署名 | Nameplate Sparkle EdDSA | private key |
| Octopool | Octopool Proxy Secret、Octopool Admin Token (OpenClaw account) | credential |
| Crabyard デプロイ | Cloudflare OpenClaw Crabyard Deploy Token | credential |
| Hetzner(crabyard) | API Key - Hetzner Cloud - OpenClaw - crabyard-ssh-gateway | credential |
| Anthropic(Peekaboo) | Anthropic API Key - Peekaboo Live Test | credential |
| ClickClack デプロイ | Cloudflare ClickClack deploy token、Cloudflare ClickClack R2 uploads | credential |
| Barnacle | GitHub Token Barnacle | credential |
| macOS Developer ID 署名(OpenClaw Foundation) | Release - macOS Developer ID p12 - OpenClaw Foundation | p12_base64、p12_password |
| macOS Developer ID 署名(個人) | Release - macOS Developer ID p12 - Peter Steinberger | 添付の DeveloperID-p12 ファイル、certificate_password |
| リリースタグ SSH 署名キー | Release - Git tag SSH signing key - all repos | private_key、public_key(fp SHA256:WmI9lVtd…) |
| Homebrew tap ディスパッチトークン | Release - Homebrew tap dispatch token - openclaw/homebrew-tap | token |
| Apple の公証(Apple ID のフォールバック) | Release - Apple ID app-specific password - notarization | apple_id、team_id、app_specific_password |
ClickClack/Barnacle の Molty 項目はエージェント用のコピーです。正式な項目は共有の OpenClaw vault にあります。ローテーション時は両方を更新してください。
リリース認証情報:タグを 1 つ指定すればすべて見つかります
署名/公証/tap の認証情報にはすべて release-credential タグが付いており、タイトルは Release - <what> - <scope> 形式です(2026-08-09 に統一)。タイトルを推測して探さず、一覧表示してください。
op item list --vault Molty --tags release-credential
まず Release - 00 INDEX (read me first) を確認してください。メモには、各 GitHub Actions シークレット名に対応する正確な項目とフィールド、および修復手順が記載されています。リリース認証情報を追加またはローテーションする際は、このインデックスを最新の状態に保ってください。
リリース認証情報:GitHub シークレットは組織レベルではなくリポジトリごとに設定
2026-08-09 に確認:openclaw 組織には組織レベルのシークレットが 21 個ありますが、リリース/署名用のものは一つもありません。MACOS_SIGNING_P12、MACOS_SIGNING_P12_PASSWORD、ASC_KEY_ID、ASC_ISSUER_ID、ASC_PRIVATE_KEY_P8、HOMEBREW_TAP_TOKEN はリポジトリごとに設定されています。そのため、署名や Homebrew への引き渡しでリリースが失敗する場合、たいていは組織レベルのシークレットの不具合ではなく、そのリポジトリでシークレットが欠落しているか、名前が違っています。
よくある落とし穴:openclaw/gogcli では古い名前(MACOS_SIGNING_CERT_BASE64、MACOS_SIGNING_CERT_PASSWORD、MACOS_CODESIGN_IDENTITY)が使われていましたが、共通の openclaw/release-workflows 再利用可能ワークフローが読み取るのは MACOS_SIGNING_P12*/ASC_* という名前だったため、署名処理へのインポートに空の値が黙って渡されていました。他のことをデバッグする前に、問題のあるリポジトリのシークレット名を正常なリポジトリ(openclaw/wacrawl)と比較してください。
これらすべての値は Molty(上の表)にあるため、リポジトリは対話なしで修復できます。フィールドの値を表示せずに読み取り、printf '%s' "$value" | gh secret set <NAME> --repo <r> でパイプしてください。--body は完全に省略してください。このフラグがない場合に限り、GitHub CLI は標準入力を読み取ります。
これらのフィールドを読むときは、以下の「正確なフィールドの読み取り」にある JSON と完全一致ラベルを使ってください。--fields label=<f> は使わないでください。2026-08-09 に Foundation の p12 アイテムで測定したところ、--fields label=p12_base64 では 65 文字が返されましたが、正しい値は 4432 文字です。隠されたフィールドが複数あるアイテムでは、誤ったフィールドが黙って選ばれるため、切り詰められたシークレットが CI に渡されるおそれがあります。
設計上、Molty の外にあるもの(デスクトップ経由、事前に同意を得ること):OpenClaw Developer ID Release Keychain(OpenClaw-Core vault)、npm の対話ログイン+OTP(Private/Npmjs)、個人用 SSH/署名キー。Twilio には API 認証情報がどこにも保存されておらず、コンソールログイン(Private)のみです。認証情報を発行するにはコンソールが必要です。
リモートルーティング - デスクトップ経由のみ
パス 2(対話型/デスクトップ)のフローにのみ適用されます。パス 1 のサービスアカウントによる読み取りは常にローカルで実行され、ルーティングされません。
- まず現在のホストを特定し(
hostname; id -un)、その環境に一致するリモート Mac スキルを読み込んでください。個人用と業務管理対象の Mac の構成は分けて扱い、古い IP アドレスや一般的な「Mac Studio」という名前から身元を推測しないでください。 - 現在のホストが、使用可能な 1Password GUI セッションのある Peter の稼働中の物理ワークステーションである場合は、同意を得たデスクトップフロー全体をローカルで実行してください。個人環境では、デフォルトの稼働中ワークステーションは
steipete-studio-sfです。steipete-mbpを使うのは、Peter が使用中だと伝えた場合、または現在の状況から承認作業を行う端末だと確認できる場合に限ります。業務管理対象の環境では、検証済みの Studio をデフォルトにしてください。その環境に対応する MacBook を使うのは、Peter が承認作業を行う端末だと特定した場合、または現在の状況からそう確認できる場合に限ります。 - VM、ヘッドレスホスト、または稼働中ではないその他のワークステーションでは、対応する構成スキルに記載された Tailscale コマンドを確認し、同じ環境内の稼働中の Studio または MacBook のみを選んでください。
ssh -o ConnectTimeout=5 -o RequestTTY=no -o RemoteCommand=none <workstation-alias> 'hostname; id -un'を実行して設定済み SSH エイリアスを確認してから、対話型フロー全体をそのワークステーション専用の共有op-worktmux セッションにルーティングしてください。 - 同意のルールに変更はありません。引き続き、先にチャットで確認してください(アイテムと理由を伝えること)。ルーティングによって変わるのはプロンプトが表示される場所であり、確認が必要かどうかではありません。
- SSH チャネルを通過するのは必要なフィールドの値のみです。値を表示しないこと、形式の確認だけを行うことというルールは、両側で同じです。タスク終了時にリモートのタスクウィンドウを終了してください。
- 選択したワークステーションがオフライン、または SSH がタイムアウトする場合、Peter または現在の状況から承認作業を行う端末だと確認できる場合に限り、同じ環境内の別の物理ワークステーションを使ってください。ローカルでの代替実行には、使用可能な GUI セッションと、現在の同じ環境のホストが Peter の稼働中ワークステーションであることの明示的な確認が必要です。それ以外の場合は、VM やヘッドレスホスト上を含め、試した内容を報告して停止してください。
ワークフロー
- OS とシェルを確認します。
- tmux 内で CLI が利用できることを確認します:
op --version。 - 必須:共有の
op-workセッションを使用します。秘密情報を扱うタスク全体を通して、このセッション内にタスク用のウィンドウを1つだけ開き、タスク完了後にそのウィンドウを終了します。 - 既知または想定される Molty アイテム → サービスアカウントで直接読み取ります(パス1)。トークンが機能するか不明な場合は、
OP_LOAD_DESKTOP_APP_SETTINGS=false OP_BIOMETRIC_UNLOCK_ENABLED=false OP_SERVICE_ACCOUNT_TOKEN="$OP_SERVICE_ACCOUNT_TOKEN" op whoami </dev/null >/dev/null 2>&1; echo op_rc:$?で確認します。 - アイテムが不明 → 上の表を確認 → Molty で保管庫のスコープを指定してメタデータを検索します(サービスアカウントを使用、安全)→ その後に限り、デスクトップでの同意を求めます(パス2)。
- コマンドに失敗した場合は、同じウィンドウで
tmux send-keysを使って再実行します。再試行だけを目的に、2つ目のウィンドウやセッションを開かないでください。 - 個人用の対話フローを開始する前に、タスク用ウィンドウ内で
OP_SERVICE_ACCOUNT_TOKENとMOLTY_OP_SERVICE_ACCOUNT_TOKENの設定を解除します。その後はデフォルトで--account my.1password.comを使用し、明示的に依頼された場合を除きmy.1password.euや Titan は使用しないでください。
共有 Op Tmux セッション — 1つのセッション、タスクごとに1つのウィンドウ
このマシン上のすべての op 作業 — すべてのスキル、すべてのエージェント、すべてのタスク — は、1つの tmux サーバー(clawdbot-op.sock)と1つのセッション(op-work)を共有します。秘密情報を扱う作業で、別のソケット名、tmux サーバー、セッションを作成しないでください。セッションを追加するたびに Peter にアラートが送信され、シェル環境に秘密情報を保持したままゾンビ化します。兄弟スキル($npm、$release-mac-app、アドホックなフロー)は同じセッションを使用し、異なるのはウィンドウ名だけです。
タスクごとに、op-work 内にタスク名を付けてウィンドウを1つ作成し、ウィンドウ ID で指定し、タスク終了時にそのウィンドウを終了します。
SOCKET_DIR="${CLAWDBOT_TMUX_SOCKET_DIR:-${TMPDIR:-/tmp}/clawdbot-tmux-sockets}"
mkdir -p "$SOCKET_DIR"
SOCKET="$SOCKET_DIR/clawdbot-op.sock"
SESSION="op-work"
# 'shell' is a permanent keeper window: never send work to it, never kill it.
tmux -S "$SOCKET" has-session -t "$SESSION" 2>/dev/null ||
tmux -S "$SOCKET" new -d -s "$SESSION" -n shell
WIN="$(tmux -S "$SOCKET" new-window -d -t "$SESSION" -n "<task-slug>" -P -F '#{window_id}')"
tmux -S "$SOCKET" send-keys -t "$WIN" -- 'OP_LOAD_DESKTOP_APP_SETTINGS=false OP_BIOMETRIC_UNLOCK_ENABLED=false OP_SERVICE_ACCOUNT_TOKEN="$OP_SERVICE_ACCOUNT_TOKEN" op whoami </dev/null >/dev/null 2>&1; echo op_rc:$?' Enter
tmux -S "$SOCKET" capture-pane -p -J -t "$WIN" -S -200
サービスアカウントで op を使う際は、3つの防御策が必須です。OP_LOAD_DESKTOP_APP_SETTINGS=false でデスクトップ設定の読み込みをスキップし、OP_BIOMETRIC_UNLOCK_ENABLED=false でアプリ連携を無効にし、リダイレクトまたはキャプチャによって標準入力/出力がペインの TTY に接続されないようにします。生体認証の上書きだけでは不十分です。op 2.35 では、強制ポリシーの起動時に 1Password アプリのグループコンテナ設定も読み取られます。macOS はその後、App Data Protection ダイアログ(「op would like to access data from other apps」)を表示し、応答されるまで open() をブロックします。これらの上書きを省略して op を TTY 上で直接実行できるのは、同意を得たデスクトップフロー(パス2)のみです。OP_LOAD_DESKTOP_APP_SETTINGS は署名済みの 2.35 バイナリでは認識されますが、公開されている環境変数のドキュメントには記載されていません。op の更新後は、プロンプトなしの whoami と TCC ログによる証明を再度行ってください。
macOS App Data のダイアログが繰り返し表示される場合
op 2.35 を使用した macOS 26 で確認されています。TCC は SystemPolicyAppData の承認をセッション/PID 単位で記録します(auth_value=5 と承認した PID)。そのため、後から起動した別の op の PID では、「許可」をクリックしていても再度確認を求められることがあります。また、各実行ファイルのパス(~/bin/op、Homebrew Caskroom のバージョン、一時コピーなど)も、それぞれ別の TCC クライアントとして扱われます。パスを固定すると識別子の数は減りますが、PID 単位の承認の問題は解消できません。
2026-07-16 の実証結果:OP_BIOMETRIC_UNLOCK_ENABLED=false のみを設定したサービス トークンでの op whoami は、確認を求めたままハングしました。OP_LOAD_DESKTOP_APP_SETTINGS=false を追加すると、新たな SystemPolicyAppData の確認なしで正常に完了しました。
ダイアログが繰り返し表示される場合、通常は op コマンドが並行実行または再試行されているか、古い op daemon プロセスが残っています。再試行ループを停止し、プロセスの引数を表示せずに pgrep -x op と共有ソケットのペインを確認してください。サービスアカウントの作業を再実行する場合は、必要なオーバーライドを指定してください。デスクトップで作業する場合は、同意済みのタスクウィンドウを 1 つだけ使用し、新しい op プロセスの起動を最小限に抑えてください。永続的な許可を期待して「許可」を繰り返しクリックしないでください。
- タスクのすべてのコマンド、再試行、後続処理で
$WINを使い回してください。引用符、項目名、コマンドに誤りがあった場合は、新しいウィンドウやセッションを作成せず、同じウィンドウに修正したコマンドを送信してください。 - タスク終了時(成功・失敗を問わず):
tmux -S "$SOCKET" kill-window -t "$WIN"— エクスポートされたシークレットはウィンドウのシェルとともに破棄されます。keeper ウィンドウは、次のタスクに備えてop-workを維持します。 - ブートストラップで
op signinを実行しないでください。サインインは、同意済みのデスクトップフロー(パス 2)の場合に限り、タスクウィンドウ内で行います。 - クラッシュしたエージェントの古いタスクウィンドウは、ペインにアイドル状態のプロンプトが表示されていれば終了してかまいません。実行中のコマンドがあるウィンドウは終了しないでください。また、
shellは終了しないでください。
サービス固有のワークフロー
- サービス固有の認証情報は、管理元のスキルに記載してください。
- npm レジストリ/パッケージの作業では
$npmを使用してください。Molty サービスアカウントの項目、非対話型の認証ラッパー、パッケージ予約ヘルパーについて記載されています。 - このスキルが扱うのは、一般的な 1Password のルールのみです。tmux 経由の
opのみを使うこと、対象を絞って読み取ること、タスクごとにウィンドウを分けた共有op-workセッションを使うこと、広範な列挙をしないこと、シークレットを出力しないことです。
動作確認済みのシークレット書き込み方法
新しいシークレットは、サービスアカウントを使って、プロンプトなしで Molty ボルトに作成します。個人アカウントへの書き込みは、明示的に依頼された場合に限ります。共有 op-work セッション内のタスクウィンドウ(上記のブートストラップを参照)を使用し、タスクの内容をそのまま一時スクリプトに書き込んで、ウィンドウに送信してください。再試行時に 2 つ目のウィンドウやセッションを作成しないでください。
cat > /tmp/op-store-secret.sh <<'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
set +x
export OP_LOAD_DESKTOP_APP_SETTINGS=false
export OP_BIOMETRIC_UNLOCK_ENABLED=false
exec </dev/null 2>/dev/null
VAULT="Molty"
ITEM_TITLE="Service API Tokens"
FIELD_NAME="api_token"
EXPECTED_PREFIX=""
NOTES="Created via tmux-safe op workflow"
TOKEN="$(pbpaste)"
if [ -n "$EXPECTED_PREFIX" ]; then
case "$TOKEN" in "$EXPECTED_PREFIX"*) ;; *) echo "clipboard value does not match expected prefix" >&2; exit 2;; esac
fi
OP_SERVICE_ACCOUNT_TOKEN="$OP_SERVICE_ACCOUNT_TOKEN" op item create --vault "$VAULT" --category "API Credential" --title "$ITEM_TITLE" "$FIELD_NAME[password]=$TOKEN" "notesPlain=$NOTES" >/dev/null
OP_SERVICE_ACCOUNT_TOKEN="$OP_SERVICE_ACCOUNT_TOKEN" op item get "$ITEM_TITLE" --vault "$VAULT" --fields "label=$FIELD_NAME" >/dev/null
echo "stored and verified secret field without printing it"
SCRIPT
chmod 700 /tmp/op-store-secret.sh
tmux -S "$SOCKET" send-keys -t "$WIN" -- "bash /tmp/op-store-secret.sh; rm -f /tmp/op-store-secret.sh" C-m
この CLI ビルドでは、op のカテゴリ文字列は人間が読める形式で、大文字と小文字が区別されます。api_credential ではなく "API Credential" を使用してください。
フィールドの正確な読み取り
既知の項目を実際に使用する前に、フィールドの形式を確認してください。確認するのは長さ、想定されるプレフィックス、改行の数に限り、値そのものは確認しないでください。項目に重複した認証情報フィールドや古い認証情報フィールドがある場合、op --field NAME と --fields label=NAME は、隠された別のフィールドを返すことがあります。形式が正しくない場合は、既知の項目を JSON として読み取り、正確なラベルを指定して抽出してください。
cat > /tmp/op-read-field.sh <<'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
set +x
ITEM_TITLE="Known API Credential Item"
FIELD_LABEL="api_token"
VAULT="Molty"
value="$(
OP_LOAD_DESKTOP_APP_SETTINGS=false \
OP_BIOMETRIC_UNLOCK_ENABLED=false \
OP_SERVICE_ACCOUNT_TOKEN="$OP_SERVICE_ACCOUNT_TOKEN" \
op item get "$ITEM_TITLE" --vault "$VAULT" --format json </dev/null |
FIELD_LABEL="$FIELD_LABEL" node -e 'let s=""; process.stdin.on("data",d=>s+=d); process.stdin.on("end",()=>{const item=JSON.parse(s); const f=(item.fields||[]).find(x=>x.label===process.env.FIELD_LABEL); if(!f?.value) process.exit(2); process.stdout.write(f.value);})'
)"
echo "field_len:${#value}"
case "$value" in sk-*) echo "field_prefix:sk" ;; *) echo "field_prefix:other" ;; esac
echo "field_has_newline:$(printf %s "$value" | wc -l | tr -d ' ')"
SCRIPT
chmod 700 /tmp/op-read-field.sh
tmux -S "$SOCKET" send-keys -t "$WIN" -- "bash /tmp/op-read-field.sh; rm -f /tmp/op-read-field.sh" C-m
JSON の抽出対象は既知の項目とボルトに限定してください。候補を探すためにボルトや項目を列挙しないでください。
項目の明示的な検索
ユーザーから明示的に検索を依頼された場合、スクリーンショットや一覧が提供された場合、または正確なタイトルの推測が外れた場合に限り、これを使用してください。ボルト(Molty、サービスアカウント)の範囲内で検索し、メタデータのみを扱ってください。候補のタイトル/ID/カテゴリ/ボルト名を出力し、フィールドや値は出力しないでください。まず、スクリーンショットに表示されている正確な文字列(ボルト名、項目タイトル、フィールドラベル)を優先してください。
cat > /tmp/op-find-item.sh <<'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
set +x
VAULT="Molty"
QUERY="minimax"
OP_LOAD_DESKTOP_APP_SETTINGS=false \
OP_BIOMETRIC_UNLOCK_ENABLED=false \
OP_SERVICE_ACCOUNT_TOKEN="$OP_SERVICE_ACCOUNT_TOKEN" \
op item list --vault "$VAULT" --format json </dev/null |
QUERY="$QUERY" VAULT="$VAULT" node -e '
let s=""; process.stdin.on("data",d=>s+=d); process.stdin.on("end",()=>{
const q=process.env.QUERY.toLowerCase();
const vault=process.env.VAULT;
const items=JSON.parse(s).filter(x => [
x.title, x.id, x.category, ...(x.tags || [])
].filter(Boolean).join("\n").toLowerCase().includes(q));
for (const item of items.slice(0, 10)) {
console.log(`title:${item.title} id:${item.id} category:${item.category || ""} vault:${vault}`);
}
console.log(`matches:${items.length}`);
})'
SCRIPT
chmod 700 /tmp/op-find-item.sh
tmux -S "$SOCKET" send-keys -t "$WIN" -- "bash /tmp/op-find-item.sh; rm -f /tmp/op-find-item.sh" C-m
候補を選んだ後は、正確な項目/フィールドの JSON 抽出と、形式のみの検証に切り替えてください。Molty に一致する項目がなければ、個人ボルトを黙って読み取らず、デスクトップでの同意を求めてください(パス 2)。
マスキングしたデバッグ
対話型フローのデバッグに限ります(同意済みのデスクトップ経路)。処理全体を同じタスクウィンドウ内で行ってください。ステータスと出力の長さを確認し、シークレットの値は確認しないでください。
cat > /tmp/op-debug.sh <<'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
set +x
SIGNIN_OUTPUT="$(op signin --account my.1password.com 2>&1 || true)"
echo "signin output bytes: ${#SIGNIN_OUTPUT}"
op account list 2>&1 | sed -E "s/(xox[baprs]-)[A-Za-z0-9-]+/\\1REDACTED/g; s/(xapp-)[A-Za-z0-9-]+/\\1REDACTED/g"
SCRIPT
chmod 700 /tmp/op-debug.sh
tmux -S "$SOCKET" send-keys -t "$WIN" -- "bash /tmp/op-debug.sh; rm -f /tmp/op-debug.sh" C-m
ガードレール
- シークレットをログ、チャット、コードに貼り付けないでください。
- Path-1 の
opコマンドでは、必ずOP_LOAD_DESKTOP_APP_SETTINGS=falseとOP_BIOMETRIC_UNLOCK_ENABLED=falseを設定し、サービスのトークンを明示的に渡し、標準入力とシークレットを含む標準出力をペインの TTY に出さないでください。 opを実行するたびに、バックグラウンドでop daemonが起動することがあります(2.35 ではキャッシュのフラグで防止できません)。古いデーモンによってダイアログが再表示されることがあります。opのタスクが実行中でない場合に限り、pkill -f 'op daemon'は安全です。実行中のopコマンドを広範囲に終了させないでください。- App Data の「Allow/Don't Allow」の選択は PID ごとに適用され、次の
opプロセスで再度表示される場合があります。ダイアログを承認し続けるのではなく、元のコマンドを停止し、その呼び出し方を修正してください。 - rc ファイルで
eval "$(op completion zsh)"を無条件に実行しないでください。シェルの起動ごとにopが実行され、ダイアログが繰り返し表示される既知の原因になります。 - シークレットをディスクに書き込むのではなく、
op run/op injectを優先してください。 - デスクトップアプリの経路は、チャットで明示的に同意を得た後にのみ使用してください。その後は、1Password のロック解除プロンプトで実際の認証が処理されます。プロンプトの表示中にチャットで追加のやり取りをする必要はありません。
- アプリ連携なしでのサインインが必要な場合は、
op account addを使用してください。 - 同意を得た対話フローでコマンドが「account is not signed in」を返した場合は、tmux 内で
op signinを再実行し、Peter がアプリで承認するまで待ってください。 sagは、同意を得たロック解除プロンプトへの応答がない場合にのみ使用してください。事前警告としては使用しないでください。- tmux の外で
opを実行しないでください。tmux を利用できない場合は停止して確認してください。