dsh-keychain-credentials

macOS Keychain credentials provider for DeepSeek Harness (dsh).

The stock provider (dsh-credentials-local) stores secrets in $DSH_HOME/.credentials.yaml with 0600 permissions. As its own README states: that file is protected from other OS users, but not from the model — tool processes (bash, filesystem tools) run as the same user and can read it like any other file.

This provider moves secrets into the macOS login keychain. A file that does not exist cannot be cat-ed; nothing lands in backups, sync folders, or git.

What this buys you

• Fixed: the secret is no longer a file. The stock file is reachable by every read primitive the model has — read, cat, grep, tar, node -e …, in-process or subprocess. With this provider, values live in the login keychain.
• Not fixed (be honest): while the login keychain is unlocked (the default once you are logged in), any same-user process can read the item by invoking /usr/bin/security — the CLI is ACL-trusted and no prompt appears. An agent with an unrestricted shell that knows to ask the keychain can still exfiltrate. Pairing with a sandbox that constrains tool subprocesses narrows this; a hard boundary needs OS-level separation (a signed broker with a private access group, e.g. keyringseam, or a separate OS user).

Net: the bar rises from "any read primitive" to "must exec /usr/bin/security as the same user" — a real improvement, not a complete boundary.

Why this one, not the others

• Full seam coverage: implements both halves of ctx.credentials — refs (API keys) and records (structured credentials like client-connection/browser-session grants). Several other providers implement only the refs half, which means DSH's own session records fall back to the plaintext file.
• Zero build step: pure JavaScript, no Swift, no code-signing certificate, no Xcode. Install and go.
• No auth prompts: reads and writes never ask the user for Touch ID / password. (That is a deliberate trade: keyringseam offers device-owner authentication at the cost of a prompt on every operation.)

Requirements

• macOS (/usr/bin/security)
• DeepSeek Harness ≥ 0.1.0-rc.6

Install

dsh plugin --profile web add dsh-keychain-credentials
# or from source:
dsh plugin --profile web add github:<you>/dsh-keychain-credentials

Then the bundle's cordis.patch.yml disables the stock provider and mounts this one. If you prefer to wire it by hand, add to your patch layer (~/.dsh/cordis.patch.yml or --patch <file>):

- id: credentials
  disabled: true
- insert:
    - id: credentials-keychain
      name: dsh-keychain-credentials
      config:
        servicePrefix: dsh-credentials   # keychain service prefix
        account: dsh                     # keychain account name

Usage

Store a secret (account = credential reference name):

security add-generic-password -U -s dsh-credentials -a DEEPSEEK_API_KEY -w 'sk-…'

The LLM adapter resolves the reference per request — no restart needed after rotation.

Semantics kept from the seam contract:

• Process environment shadows the keychain (per-run operator intent wins).
• An empty stored value counts as absent.
• set/unset reject while a read-only source (the environment) shadows the ref.
• describe checks existence without reading the value — a status query never pulls plaintext into the agent process.
• Errors from the security CLI are sanitized: exit code and stderr only, never the command line (which would carry the secret on a failed set).
• Secrets are fed to security over stdin, never argv, so they never appear in ps.

Test

npm test

Requires a real DSH node_modules (peer deps) — run from a profile with @deepseek-ai/dsh-credentials installed, or symlink one.

License

MIT