---
summary: Two credvault behaviors that surface in bulk/scripted use — intermittent bw-sync failures needing retry with 20s+ backoff, and the trailing newline on get --secret-only that breaks naive hash comparisons.
tags:
  - type/reference
  - tool/credvault
scope: global
date: 2026-07-13
---

# credvault behaviors under bulk/scripted use

Discovered 2026-07-13 during a 33-key backfill loop (`credvault ensure --secret-file` per key).

## 1. Intermittent `bitwarden_command_failed` ("bw sync failed") under rapid calls

When credvault is invoked many times in quick succession, the underlying `bw sync`
intermittently fails and the CLI returns `bitwarden_command_failed`. It is transient:
the same call succeeds on retry. Backoff matters — 8s between retries was not always
enough; 20s+ per retry (up to 5 attempts) cleared every failure.

**Rule:** any bulk credvault loop must retry specifically on `bitwarden_command_failed`
with ≥20s backoff, and classify per-key outcomes (`created`/`existing`/`secret_conflict`/
`missing-source`/failed) rather than aborting the whole run.

## 2. `get --secret-only` output ends with a trailing newline

When verifying a stored value against its source by hash, the vault side includes a
trailing `\n` that a `tr -d '\n'`-stripped source does not — producing false MISMATCHes.
Normalize both sides first:

```bash
credvault get <key> --secret-only | tr -d '\n' | sha256sum
```

(Values that are genuinely multi-line files, e.g. a service-account JSON stored via
`--secret-file`, round-trip byte-identical and compare fine without stripping.)

## Related

- [[credvault-locked-status-is-not-blocking]]