Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When 1Password service account credentials fail to resolve (rate limit, network issue, token expiry), the gateway enters a crash-loop via launchd KeepAlive, repeatedly invoking op read for every configured secret provider on each restart. This quickly exhausts 1Password's account-wide daily rate limit, making recovery impossible for up to 24 hours.

Steps to reproduce

1. Configure gateway with multiple op read-based secret providers in openclaw.json
2. Run gateway as a LaunchAgent with KeepAlive: true
3. Trigger a transient 1Password failure (e.g., expired token, network blip, or rate limit)
4. Observe the restart loop

Expected behavior

The gateway should detect repeated secret resolution failures and back off rather than crash-looping into a rate limit:

• Exponential backoff on secret provider failures (e.g., 1s → 2s → 4s → ... → cap at 5 minutes)
• Circuit breaker — after N consecutive failures, stop retrying and log a clear error instead of exiting (which triggers launchd restart)
• Batch secret resolution — use op run to resolve all secrets in a single CLI invocation instead of individual op read calls per provider
• Rate limit awareness — detect "Too many requests" responses and pause rather than retrying immediately

Actual behavior

1. Gateway starts → secret providers invoke op read for each configured secret
2. One or more op read calls fail (timeout or error)
3. Gateway exits with SecretProviderResolutionError
4. launchd restarts gateway after ThrottleInterval (30s default)
5. Goto 1

Each restart cycle fires N op read calls (one per provider). With ~6 providers and a 30s restart interval, this produces ~720 op calls/hour. In practice we observed 281,000+ requests in under 24 hours, far exceeding 1Password's account-wide daily limit (50K for Business, 5K for Teams).

Once the daily limit is hit, all op calls fail across all service accounts on the 1Password account, and recovery requires waiting up to 24 hours.

OpenClaw version

2026.3.24

Operating system

macOS 26.3.1 (25D2128)

Install method

No response

Model

NA

Provider / routing chain

NA

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

• Exhausts 1Password rate limits for the entire account (not just one service account)
• Blocks all 1Password API access for up to 24 hours
• Affects all services sharing the same 1Password account
• Requires manual intervention to stop the loop

Additional information

Summary

When 1Password service account credentials fail to resolve (rate limit, network issue, token expiry), the gateway enters a crash-loop via launchd KeepAlive, repeatedly invoking op read for every configured secret provider on each restart. This quickly exhausts 1Password's account-wide daily rate limit, making recovery impossible for up to 24 hours.

Environment

• OpenClaw: 2026.3.24 (cff6dc9)
• macOS (Apple Silicon), launchd LaunchAgent with KeepAlive: true
• 1Password CLI v2.33.0, service account auth via OP_SERVICE_ACCOUNT_TOKEN
• Secret providers configured via openclaw.json secrets.providers (exec-based op read)

Steps to Reproduce

1. Configure gateway with multiple op read-based secret providers in openclaw.json
2. Run gateway as a LaunchAgent with KeepAlive: true
3. Trigger a transient 1Password failure (e.g., expired token, network blip, or rate limit)
4. Observe the restart loop

What Happens

1. Gateway starts → secret providers invoke op read for each configured secret
2. One or more op read calls fail (timeout or error)
3. Gateway exits with SecretProviderResolutionError
4. launchd restarts gateway after ThrottleInterval (30s default)
5. Goto 1

Each restart cycle fires N op read calls (one per provider). With ~6 providers and a 30s restart interval, this produces ~720 op calls/hour. In practice we observed 281,000+ requests in under 24 hours, far exceeding 1Password's account-wide daily limit (50K for Business, 5K for Teams).

Once the daily limit is hit, all op calls fail across all service accounts on the 1Password account, and recovery requires waiting up to 24 hours.

Expected Behavior

The gateway should detect repeated secret resolution failures and back off rather than crash-looping into a rate limit:

• Exponential backoff on secret provider failures (e.g., 1s → 2s → 4s → ... → cap at 5 minutes)
• Circuit breaker — after N consecutive failures, stop retrying and log a clear error instead of exiting (which triggers launchd restart)
• Batch secret resolution — use op run to resolve all secrets in a single CLI invocation instead of individual op read calls per provider
• Rate limit awareness — detect "Too many requests" responses and pause rather than retrying immediately

Workaround

We've implemented these protections in our own code that calls op (Mission Control), but the gateway's internal secret provider resolution doesn't have them. Current workaround is to manually unload the LaunchAgent when failures occur:

launchctl bootout gui/$(id -u)/ai.openclaw.gateway

Impact

• Exhausts 1Password rate limits for the entire account (not just one service account)
• Blocks all 1Password API access for up to 24 hours
• Affects all services sharing the same 1Password account
• Requires manual intervention to stop the loop

Suggestion

Consider adding a secrets.retryPolicy option to openclaw.json, e.g.:

{
  "secrets": {
    "retryPolicy": {
      "maxRetries": 3,
      "backoffMs": [1000, 2000, 4000],
      "circuitBreakerThreshold": 2,
      "cooldownMs": 300000
    }
  }
}

Or at minimum, if all secret providers fail on startup, exit with a non-zero code that signals "do not restart immediately" rather than a generic crash that launchd treats as restartable.