Bring your existing credentials into Skarbiec.

Seed a real vault from 1Password, Bitwarden, a browser password export, or canonical Skarbiec rows without entering each item again.

Start with your own export#

  1. Export your data from its current owner. Prefer 1Password 1PUX or unencrypted Bitwarden JSON to retain more information than CSV.
  2. Select an existing Skarbiec vault, or create one. The CLI uses SKARBIEC_VAULT_FILE; Desktop offers vault selection and creation inside Import existing items.
  3. Import the file, keeping existing values by default. No workload grants or provider sessions are created by the import.
  4. Read the per-item result and open an actual saved item. Keep your original export until you have checked the records and attachments you need.
1Password
skarbiec import account.1pux --format 1password
Bitwarden
skarbiec import bitwarden.json --format bitwarden
During setup
skarbiec onboarding --import passwords.csv --format browser-csv

Supported exports#

Imported item ids contain a short title-derived label and a stable source-identity suffix. Ids and tags are visible vault metadata; credential values and original source records are encrypted.

1Password account/vault/item UUIDs and Bitwarden item UUIDs identify repeated imports. CSV files without UUIDs use their non-secret title, URL, username, folder and type; ambiguous duplicate identities are refused rather than merged by guessing.

Archived 1Password records are retained as bundles instead of being activated as native logins. Standard Base32 and otpauth TOTP values using SHA1, six digits and 30 seconds become native seeds; other authenticator settings remain in the encrypted source and produce an explicit warning.

Only data actually present in the export can be imported. For example, 1Password desktop exports omit passkeys, and ordinary Bitwarden JSON/CSV exports omit attachment bytes.

SourceFormatResult
1Password1PUX version 3Native logins and notes, retained source records, and encrypted bundles for documents, attachments and custom icons.
1Passwordexport.data JSON or CSVThe supplied records and fields. These files do not contain the archive's attachment bytes; use 1PUX when attachments matter.
BitwardenUnencrypted JSONNative logins and secure notes; cards, identities and other types remain complete encrypted bundles. Folder/collection records, custom fields and history are retained with their source item.
BitwardenCSVLogins, notes and every supplied column. CSV does not contain the fields or attachments its exporter omitted.
BrowsersPassword CSVURL, username, password, notes and supported authenticator fields; all supplied columns remain in the encrypted source record.
SkarbiecCanonical JSON arrayExact id/payload rows, with optional existing recipient identities and tags. Legacy payloads require `skarbiec upgrade --apply` first.

Existing values and repeat imports#

  • keep is the default: identical records are unchanged, changed existing records are retained and reported as kept_existing, and new records are added.
  • replace writes a new revision only when the imported value differs. Source-imported items retain their existing recipient and tag assignments; their original vault ids survive local renaming.
  • error refuses the whole import on a changed existing record. All accepted rows are parsed, checked and encrypted before one vault save, so malformed input, encryption failure or a concurrent vault change cannot leave a partially imported batch.
  • Lifecycle-managed and non-owner-controlled items cannot be replaced by any conflict policy. Canonical imports also refuse unknown recipients, reserved managed:weles tags and newly introduced unregistered tag namespaces.
Explicit replacement
skarbiec import account.1pux --format 1password --conflict replace
Refuse conflicts
skarbiec import rows.json --format canonical --conflict error

Desktop and saved values#

The graphical import calls POST /v1/operator/items/import on the configured loopback backend with path, format, conflict and vault. That route invokes the same importer as the CLI and participates in the normal vault write lock.

The CLI reads the complete retained payload with skarbiec credential get <item-id>. Native fields remain available to normal get --field and acquisition operations after the owner grants their usual capabilities.

Desktop requires a backend containing the 0.3.0 import endpoint. An older or unavailable backend returns its actual refusal in the import screen; the interface does not report success from file selection alone.

Desktop finds its backend at SKARBIEC_URL when it is set, otherwise at the address Stado's service directory wrote for this machine into ~/.stado/forwards/skarbiec.local (stado service directory publish). It has no built-in port: with neither, Settings shows the backend as Unavailable and every request is refused with that sentence. A SKARBIEC_URL that is set but is not an absolute URL with a scheme and a host is refused by name and never replaced by the service directory; a marker that exists but cannot be read, or whose first line is not such a URL, is refused with its path and cause instead of being treated as absent.

An explicitly empty SKARBIEC_URL is also refused as an invalid declaration. Remove that environment entry to select the service-directory address; leaving it present with no value never selects another backend.

A connection failure the operating system reports, whatever its cause, retains the attempted endpoint, the system's error code and its concrete explanation in the native failure detail. A missing address retains its configuration refusal instead of being replaced with a generic unavailable sentence. These diagnostics do not assert that a vault read or mutation succeeded.

A non-HTTP response is refused. An unsuccessful HTTP response with malformed JSON reports the status and decoding cause; a missing or empty error field is named explicitly. Valid backend error text is preserved. Failure to construct the requested endpoint never sends the request to the bare base address instead.

Every native HTTP refusal retains the observed status alongside the backend's detail. When no detail was returned, the screen names that absence and the status instead of replacing both with a generic failure sentence.

Endpoint configuration refusals are distinct from failed connections: a DNS lookup or connection failure at a declared endpoint is reported as a failure, not as proof that no backend was configured. A connection the operating system reports as expired keeps its own classification.

Posture reports a failed GnuPG daemon check without assuming that memory exceeded its ceiling. Missing settings and failed process measurements retain the backend's complete cause in the failure alert; only the reported measurement establishes an actual excess.

  1. Choose Import existing items in first use or on Items. The empty-vault view offers the same action.
  2. If no vault is selected, choose one or enter an owner identity and a new vault path in the import screen.
  3. Choose the export, format and changed-item policy, then select Import into this vault.
  4. Read the returned counts and warnings. Open saved item reads the vault, not the input file; Items also offers Open saved value after the import window closes.
  5. Use Copy full record or Save complete JSON for the complete saved payload. Attachment bundles also offer Save attachment; saved files are owner-readable and owner-writable.

Refusals and limits#

  • Bitwarden export is encrypted; export an unencrypted JSON file and import it locally
  • CSV does not have supported 1Password, Bitwarden, or browser export headers
  • unsupported 1PUX export version; export version 3 from 1Password
  • import contains no items
  • An import reads the whole export and every row in it; no file size, archive size or item count is refused.
  • The source export is never modified or deleted. Import results contain metadata and warnings, not secret values.