declaw vault manages secrets for the credential vault. A stored secret is injected into outbound requests at the egress proxy and never enters the VM — a sandbox references it by name (via declaw sandbox create --vault-ref ENV_VAR=secret-name) and only ever sees a placeholder.
The easiest way to store a secret is with a built-in provider preset, which fills in the right scopes for you.
create
Store a secret. Use--provider to apply a preset, or --scope to specify scopes manually. A scope is domain_regex,injection_type[,header_name].
| Flag | Default | Description |
|---|---|---|
--value | The secret value (required) | |
--name | Secret name (defaults to the provider key when --provider is set) | |
--provider | Preset key (e.g. openai, anthropic) that supplies the scopes | |
--scope | Scope domain_regex,injection_type[,header_name]. Required unless --provider is set. Repeatable | |
--rotation-days | 0 | Days until rotation is due (0 = no rotation reminder) |
list
List your secrets (aliasls) with their injection type, domains, and rotation due date. Values are never shown.
rotate
Replace a secret’s value by name. Existing sandboxes pick up the new value on their next outbound request — no restart needed.update-scopes
Replace a secret’s injection scopes by name — point it at a new destination or change the injection format — without re-supplying the value.--scope is repeatable (domain_regex,injection_type[,header_name]). Running sandboxes pick up the new scopes on their next outbound request.
delete
Delete a secret by name.presets
List the built-in provider presets you can pass to--provider.
Next steps
- Credential vault — how injection at the egress proxy works
- Sandbox commands — reference a secret with
--vault-ref