Preface

When developing the DeepSeek Harness (DSH) plugin, a very specific problem arises: the model needs to read usernames, emails, phone numbers, passwords, TOTP secrets, as well as SSH/API keys and OAuth developer credentials, but this information should not be scattered across prompts, temporary scripts, chat contexts, or ordinary configuration files.

dsh-vault solves exactly this: it is an encrypted credential vault plugin designed for DSH, storing the aforementioned sensitive information encrypted on disk and providing controlled access through model tools and a Settings UI.

What This Is

Ox0400/dsh-vault is an encrypted credential vault plugin for DeepSeek Harness, authored by Ox0400, licensed under MIT.

Its primary positioning is:

  • Store sensitive credentials, encrypted on disk.
  • Expose CRUD, search, password generation, and TOTP tools to the model.
  • Provide a Settings UI page.
  • Support subsequent maintenance capabilities, such as password history, recovery codes, rekeying, backups, import/export, attachments, expiration, rotation, health checks, and batch operations.

Core Capabilities

Encrypted Storage Scope

Based on verified facts, dsh-vault can store:

  • Usernames
  • Emails
  • Phone numbers
  • Passwords
  • TOTP secrets
  • SSH connections
  • API keys
  • Secrets
  • OAuth access/refresh tokens

These credentials are encrypted when persisted to disk.

Model Tools

The plugin exposes credential management tools to the model, with common tools including:

  • vault_add: Adds a new credential entry, allowing flexible combinations of different fields.
  • vault_get: Reads a complete entry by id, including ciphertext fields.
  • vault_search: Searches by title, category, username, email, phone, host, port, URL, notes, tags, custom fields, etc., returning summaries without ciphertext.
  • vault_update: Updates fields by id; an empty string clears the corresponding field.
  • vault_totp: Generates the current 6-digit TOTP code for a stored otpSecret.
  • vault_generate_password: Generates a strong random password or a memorable passphrase.
  • vault_lock / vault_unlock: Locks the credential vault or re-unlocks it.

Search Does Not Return Ciphertext

vault_search only returns summaries and does not return passwords, keys, tokens, or TOTP secrets.

To read full credentials, you must explicitly use vault_get by id.

This separates “finding entries” from “reading ciphertext”: the model can first search to locate, then decide whether it needs to read the full content.

Implementation Details

dsh-vault uses Node’s built-in node:crypto and introduces no additional encryption dependencies.

Verified facts mention:

  • AES-256-GCM encryption
  • scrypt key derivation
  • RFC 6238 TOTP

The key derived from the master password is used as follows:

key = scrypt(master password, salt)

The derived key is cached in the process and is never persisted to disk. It is re-derived after a restart.

Additionally, verified facts mention:

  • Soft-deleted entries move to trash and remain encrypted on disk.
  • Batch deletion defaults to dry-run, requiring confirm: true.
  • vault_breach_check uses Have I Been Pwned k-anonymity; only the SHA-1 prefix leaves the machine, with an offline common-password fallback.

Installation and Enablement

The verified materials do not provide a confirmed official installation command, so no installation command is given here directly.

Do not fabricate commands like dsh plugin add github:owner/repo based on the repository name. Please confirm the installation method from the repository README or the plugin directory page first.

Below are verified details related to pre-installation checks:

name: dsh-vault
version: 1.10.9-rc.1
license: MIT
node engine: >=20
dependencies: playwright-core
peer dependencies: @deepseek-ai/* packages

Before enabling, it is recommended to confirm that the local Node version satisfies >=20 and to check whether the required @deepseek-ai/* peer dependencies are installed.

Typical Usage

The following is explained in the order of actual operation.

1. Search first, don’t read ciphertext directly

When the model only knows an account’s email, hostname, tag, or title, use vault_search first.

It returns summaries without ciphertext.

The benefit is that the search process does not bring passwords, API keys, OAuth tokens, or TOTP secrets into the model context.

2. Read after confirming the entry

If the target entry appears in the search results, then use vault_get by id to read the full entry.

Only explicit reads retrieve the full credentials.

3. Add new credentials

When you need to save new login information, SSH connections, API keys, or OAuth tokens, use vault_add.

vault_add supports any combination of fields, suitable for entering usernames, emails, passwords, hosts, ports, keys, tokens, notes, tags, and more in one go.

4. Update fields

Use vault_update when you need to modify an entry.

Fields not provided are preserved; if a field is passed an empty string, that field will be cleared.

5. Generate a password or passphrase

Use vault_generate_password when you need a password for a new account.

It can generate strong random passwords or memorable passphrases.

6. Get TOTP codes

If the entry contains a TOTP secret, you can use vault_totp to generate the current 6-digit dynamic code.

This is suitable for scenarios where you need to temporarily read an MFA code.

7. Lock and unlock

Use vault_lock when the credential vault is no longer needed by the model or when you need to clear the cached key from the process.

Use vault_unlock when access is needed again.

Applicable Scenarios and Notes

Scenarios suitable for dsh-vault:

  • Providing credential access capabilities to DSH plugins or agents.
  • Managing identity credentials such as usernames, emails, phone numbers, passwords, and TOTP secrets.
  • Managing SSH connections, API keys, secrets, and OAuth access/refresh tokens.
  • Wanting to search credentials without directly exposing passwords, keys, tokens, or TOTP secrets.
  • Wanting to handle credential maintenance in the Settings UI and model tools rather than scattering them across ordinary configuration files.

Points to note:

  • The plugin runs with the permissions of the current dsh process.
  • Before installation, it is recommended to inspect the source code, dependencies, license, and usage methods.
  • The verified materials do not provide an official installation command; do not fabricate one.
  • Search only returns summaries; full credentials still require explicit vault_get.
  • Batch deletion defaults to dry-run and requires confirm: true.

Conclusion

The value of dsh-vault lies in separating “the model can search credentials” from “the model can read full ciphertext” into two steps, while storing sensitive information encrypted on disk.

For plugin development scenarios that require managing accounts, developer credentials, and MFA keys within DSH, it is an encrypted credential vault plugin worth examining.

Repository address:

https://github.com/Ox0400/dsh-vault