Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Exec provider: 1Password op CLI spawns daemon processes, hangs on macOS Tahoe (needs --cache=false) [1 participants]

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…
GitHub stats
openclaw/openclaw#55459•Fetched 2026-04-08 01:39:17
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
thecolormarounthecolormaroun
Participants
thecolormarounthecolormaroun
Timeline (top)
subscribed ×2

When using op (1Password CLI v2.33.0) as an exec secret provider, the op binary spawns op daemon --background processes by default for its caching layer. On macOS Tahoe (26.3.1), these daemon processes trigger TCC permission dialogs ("node would like to access data from other apps") and hang indefinitely, causing SecretProviderResolutionError timeouts on every provider.

Because the gateway retries secret resolution on startup failure, each attempt spawns 4+ additional daemon processes (one per secret), rapidly accumulating 80+ zombie op daemon processes that flood the user with TCC dialogs and prevent the gateway from ever starting.

Root Cause

Because the gateway retries secret resolution on startup failure, each attempt spawns 4+ additional daemon processes (one per secret), rapidly accumulating 80+ zombie op daemon processes that flood the user with TCC dialogs and prevent the gateway from ever starting.

Fix Action

Workaround

Add "--cache=false" as the first element of the provider's args array:

{
  "source": "exec",
  "command": "/opt/homebrew/bin/op",
  "args": ["--cache=false", "read", "--no-newline", "op://vault/item/field"],
  "passEnv": ["OP_SERVICE_ACCOUNT_TOKEN", "HOME", "OP_BIOMETRIC_UNLOCK_ENABLED", "OP_CONFIG_DIR"]
}

The daemon is unnecessary when using service account authentication — op can resolve secrets directly via the 1Password cloud API without a local cache daemon.

Code Example

{
  "source": "exec",
  "command": "/opt/homebrew/bin/op",
  "args": ["--cache=false", "read", "--no-newline", "op://vault/item/field"],
  "passEnv": ["OP_SERVICE_ACCOUNT_TOKEN", "HOME", "OP_BIOMETRIC_UNLOCK_ENABLED", "OP_CONFIG_DIR"]
}
RAW_BUFFERClick to expand / collapse

Summary

When using op (1Password CLI v2.33.0) as an exec secret provider, the op binary spawns op daemon --background processes by default for its caching layer. On macOS Tahoe (26.3.1), these daemon processes trigger TCC permission dialogs ("node would like to access data from other apps") and hang indefinitely, causing SecretProviderResolutionError timeouts on every provider.

Because the gateway retries secret resolution on startup failure, each attempt spawns 4+ additional daemon processes (one per secret), rapidly accumulating 80+ zombie op daemon processes that flood the user with TCC dialogs and prevent the gateway from ever starting.

Environment

  • OpenClaw: 2026.3.24 (stable)
  • macOS: Tahoe 26.3.1 (arm64)
  • 1Password CLI: 2.33.0 (Homebrew cask)
  • Auth: Service account token (OP_SERVICE_ACCOUNT_TOKEN)
  • Launch context: LaunchAgent

Reproduction

  1. Configure an exec provider with op read (no --cache=false flag)
  2. Run on macOS Tahoe as a LaunchAgent
  3. Gateway fails to start with: SecretProviderResolutionError: Exec provider "op-*" timed out after 5000ms
  4. pgrep -f "op daemon" shows dozens of zombie processes

Workaround

Add "--cache=false" as the first element of the provider's args array:

{
  "source": "exec",
  "command": "/opt/homebrew/bin/op",
  "args": ["--cache=false", "read", "--no-newline", "op://vault/item/field"],
  "passEnv": ["OP_SERVICE_ACCOUNT_TOKEN", "HOME", "OP_BIOMETRIC_UNLOCK_ENABLED", "OP_CONFIG_DIR"]
}

The daemon is unnecessary when using service account authentication — op can resolve secrets directly via the 1Password cloud API without a local cache daemon.

Suggested fix

One or more of:

  1. Auto-detect op and set OP_CACHE=false — When the exec provider command ends with /op, automatically inject OP_CACHE=false into the process environment. The daemon provides no benefit in a headless/LaunchAgent context and actively breaks on macOS Tahoe.

  2. Support global flags in exec provider config — Add a globalArgs or prependArgs field so users can pass CLI-global flags (like --cache=false) that must appear before the subcommand.

  3. Document the workaround — At minimum, add a note to the 1Password exec provider docs that --cache=false is required on macOS Tahoe to prevent daemon spawning.

Related

  • #29183 (closed) — 1Password exec provider passEnv propagation
  • The com.apple.quarantine and com.apple.provenance xattrs on the op binary can also cause TCC blocking — a secondary but compounding issue.

extent analysis

Fix Plan

To resolve the issue with the 1Password CLI spawning unnecessary daemon processes, we can implement one of the suggested fixes. Here, we'll focus on the first suggestion: auto-detecting op and setting OP_CACHE=false.

Step-by-Step Solution

  1. Modify the Exec Provider Configuration:

    • When the exec provider command ends with /op, automatically inject OP_CACHE=false into the process environment.
    • This can be achieved by modifying the configuration or the code that handles the exec provider.

  2. Example Configuration Modification:

    • If directly modifying the configuration is possible, ensure it includes setting OP_CACHE=false for op commands.
    • Example configuration snippet: 
      {
  "source": "exec",
  "command": "/opt/homebrew/bin/op",
  "args": ["--cache=false", "read", "--no-newline", "op://vault/item/field"],
  "env": {
    "OP_CACHE": "false"
  },
  "passEnv": ["OP_SERVICE_ACCOUNT_TOKEN", "HOME", "OP_BIOMETRIC_UNLOCK_ENABLED", "OP_CONFIG_DIR"]
}

  3. Code Modification:

    • If the configuration cannot be directly modified, the code handling the exec provider needs to be adjusted to automatically add --cache=false when the command is op.
    • Example code snippet (in a hypothetical programming language): 
      if command.endswith('/op'):
  args.insert(0, '--cache=false')
  env['OP_CACHE'] = 'false'

Verification

  • After implementing the fix, restart the service or application using the 1Password CLI.
  • Verify that no unnecessary op daemon processes are spawned by checking the process list with pgrep -f "op daemon".
  • Ensure that the gateway starts successfully without encountering SecretProviderResolutionError timeouts.

Extra Tips

  • Regularly review and update dependencies to ensure compatibility and security.
  • Consider documenting known issues and workarounds for common configurations, such as using the 1Password CLI on macOS Tahoe.
  • Be aware of potential secondary issues, such as xattrs causing TCC blocking, and address them accordingly to prevent compounding problems.

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…
#api#training loop#device allocation#model download#tokenizer error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING