claude-code - 💡(How to fix) Fix Regression (2.1.149 → 2.1.156): 1Password `op` CLI session broke in Bash tool calls on macOS

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

A Claude Code update broke the 1Password CLI (op) inside Bash tool calls. With the 1Password desktop CLI integration off (master-password session via op signin), op works in Claude Code 2.1.149 but fails in 2.1.156 with [ERROR] no active session found for account …same machine, same session token, only the Claude Code version differs. The same token works in Terminal on both builds.

Error Message

A Claude Code update broke the 1Password CLI (op) inside Bash tool calls. With the 1Password desktop CLI integration off (master-password session via op signin), op works in Claude Code 2.1.149 but fails in 2.1.156 with [ERROR] no active session found for account …same machine, same session token, only the Claude Code version differs. The same token works in Terminal on both builds. 3. In current 2.1.156, run op whoamifails: [ERROR] no active session found for account ….

Root Cause

A Claude Code update broke the 1Password CLI (op) inside Bash tool calls. With the 1Password desktop CLI integration off (master-password session via op signin), op works in Claude Code 2.1.149 but fails in 2.1.156 with [ERROR] no active session found for account …same machine, same session token, only the Claude Code version differs. The same token works in Terminal on both builds.

Fix Action

Fix / Workaround

Impact

Breaks 1Password credential access from Bash tool calls for setups that previously worked, with no effective settings workaround (the disable flag is ineffective). Current options are pinning an old build or caching secrets to a plaintext file (a security downgrade).

RAW_BUFFERClick to expand / collapse

Summary

A Claude Code update broke the 1Password CLI (op) inside Bash tool calls. With the 1Password desktop CLI integration off (master-password session via op signin), op works in Claude Code 2.1.149 but fails in 2.1.156 with [ERROR] no active session found for account …same machine, same session token, only the Claude Code version differs. The same token works in Terminal on both builds.

Environment

  • macOS 26.4.1 (Tahoe), Apple Silicon
  • op 2.34.0 (Homebrew); 1Password desktop app integration off; session established via op signin, token exported into the shell env and sourced from ~/.zshenv (so Bash tool subshells inherit it)

A/B repro (same token, same machine)

  1. Terminal: eval $(op signin) (master password); confirm op whoamiUser Type: HUMAN.
  2. Launch the old build: DISABLE_AUTOUPDATER=1 ~/.local/share/claude/versions/2.1.149; ask Claude to run op whoamisucceeds (User Type: HUMAN).
  3. In current 2.1.156, run op whoamifails: [ERROR] no active session found for account ….

Only the Claude Code build differs between steps 2 and 3.

Notes

  • dangerouslyDisableSandbox: true does not restore it — consistent with #52471 (the flag doesn't actually lift the Seatbelt profile for Bash subprocesses).
  • sandbox.network.allowAllUnixSockets: true also did not help.
  • Likely mechanism: the Bash sandbox was enabled/changed somewhere in 2.1.149 → 2.1.156, blocking the local IPC op uses to reach its session. Related (closed): #40209 (1Password op + sandbox), #31551, #52471; open: #41817.

Impact

Breaks 1Password credential access from Bash tool calls for setups that previously worked, with no effective settings workaround (the disable flag is ineffective). Current options are pinning an old build or caching secrets to a plaintext file (a security downgrade).

Request

Treat as a regression: restore the pre-regression behavior, or make dangerouslyDisableSandbox (and/or a path-scoped Unix-socket allow) actually lift the IPC restriction so credential-manager CLIs work again.

(Reported with Claude Code.)

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Regression (2.1.149 → 2.1.156): 1Password `op` CLI session broke in Bash tool calls on macOS