← graph

implement-wg-secret

Implement: wg secret command + keyring/plaintext/passthrough backends

Metadata

Statusdone
Assignedagent-1070
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Modelclaude:sonnet
Created2026-04-29T02:24:01.860264919+00:00
Started2026-04-29T02:35:19.270652513+00:00
Completed2026-04-29T03:32:15.292156920+00:00
Tagspriority-high,fix,secrets,security, eval-scheduled
Eval score0.79
└ blocking impact0.80
└ completeness0.85
└ constraint fidelity0.55
└ coordination overhead0.85
└ correctness0.85
└ downstream usability0.75
└ efficiency0.75
└ intent fidelity0.74
└ style adherence0.85

Description

Description

Implement the credential storage system designed in design-secure-credential. Read that task's log first via wg show design-secure-credential for the chosen backend approach, schema, command surface, and failure modes.

Goal: wg profile use openrouter works without exporting OPENROUTER_API_KEY in the shell. The key lives in the OS keyring (or a configured backend), is fetched by the daemon when spawning workers, and never lands in process listings or shell history.

Scope

Per the design spec. Likely includes:

  1. wg secret subcommand (set / get / list / rm / backend show|set)
  2. Keyring backend via the keyring crate
  3. Plaintext-file backend (mode 0600, only if secrets.allow_plaintext = true)
  4. Pass-through resolver (op://, pass:, etc.) — at minimum stub the resolver interface; wire 1–2 concrete backends
  5. Profile schema: api_key_ref = "<backend>:<name>" field; back-compat for api_key_env
  6. Resolver in the dispatcher / agent spawn path: looks up the ref, injects only into the spawned worker's env (NOT exported to anything else)
  7. Pre-flight check on wg profile use: warn if the referenced secret is unreachable
  8. Migration command: wg migrate secrets — walks existing configs with api_key_env, prompts to copy values into keyring, rewrites to api_key_ref

Validation

  • Failing tests written first (TDD): set/get/list/rm against each backend; resolver hits each backend in correct order; profile pre-flight check works
  • wg secret set openrouter followed by wg profile use openrouter (where profile has api_key_ref = "keyring:openrouter") produces a working dispatcher that can spawn an OpenRouter worker — without OPENROUTER_API_KEY being set in any shell env
  • Spawned worker process: grep -i openrouter /proc/<pid>/environ shows OPENROUTER_API_KEY is set (workers still need it for the API call) but the key is NOT in the parent shell env or the dispatcher's env
  • wg secret list shows names only, never values
  • wg secret get <name> is redacted by default; --reveal actually prints (with warning)
  • wg profile use openrouter with no secret stored fails fast with actionable error: 'Run: wg secret set openrouter'
  • wg migrate secrets walks existing api_key_env entries and migrates them on user confirmation
  • cargo build + cargo test pass with no regressions
  • Permanent smoke scenarios: keyring backend round-trip; plaintext backend round-trip (with allow_plaintext=true); profile-with-secret end-to-end. This task id in owners.
  • cargo install --path . was run before claiming done

Depends on

Required by

Log