Skip to main content
Use a Vault for API keys and other private configuration your Agent needs. A Project can use a Vault you attach to it; an Agent gets access through its own workspace and linked Projects.

​
Choose which Projects can use a Vault

  1. Open your Project’s Vaults tab.
  2. Review the Vaults already in the Project.
  3. Choose Add beside an available Vault, or Create vault for a new one.
Project Vaults tab separating attached Vaults from available Vaults. Project Vaults tab separating attached Vaults from available Vaults. Attach only the Vaults this Project needs. Removing a Vault from a Project leaves its keys available to other attached Projects. Changing a shared Vault’s contents affects every Project using it.

​
Add a key in the dashboard

  1. Open the Vault and choose Add keys.
  2. Enter the key names and values in the private entry form.
  3. Review the detected keys, then save.
  4. Confirm that the saved key names appear in the Vault.
Demo Vault with DEMO_ENVIRONMENT, DEMO_REGION, and DEMO_WORKSPACE and masked values. Demo Vault with DEMO_ENVIRONMENT, DEMO_REGION, and DEMO_WORKSPACE and masked values. Saved key names remain visible. Values are write-only in this view. Light full-size image · Dark full-size image
Sharing a Project also gives its Viewers access to attached Vault values through runtime tools. Masked values in the dashboard still require careful access control. Review attachments before sharing.
Clawdi manages Vault encryption and can decrypt stored values. Keep secrets out of conversations, screenshots, and committed files. The advanced steps below show how to use references when a command or configuration file needs a key.

​
Store one secret safely

Use a masked prompt for interactive entry and name the Project explicitly:
For automation, --stdin avoids placing the value in a command-line flag:
The command creates the Vault if needed, stores the value, and prints an exact reference containing the Project ID. Copy that emitted reference instead of constructing one by hand.

​
Import an existing dotenv file

Review the source file, then import without --yes so the interactive summary and confirmation remain visible:
The import reads valid dotenv identifiers, reports invalid identifiers it skips, and writes the accepted fields into one Vault section. Existing plaintext remains in the source file; remove or retain that file according to your own secret-handling policy after you verify the import.List names and copyable references without printing values:

​
Commit references, not values

Create a template such as .env.clawdi with the exact reference printed by vault set, vault import, or vault list:
Exact references carry their Project scope and avoid ambiguous matches when an Agent has several linked Projects. Project-relative references remain useful for portable templates, but require an explicit Project, Agent, or linked folder context at resolution time.To link the current folder to a Project:

​
Run a command without writing plaintext

Preview provenance first. Dry-run does not launch the child command or request plaintext values:
Only the child process receives the resolved environment. Prefer this path to --all-vault-env, which is a legacy broad-injection mode.

​
Inject a file only when required

Some tools require a physical configuration file. Preview, then write it:
The CLI creates the output with owner-only permissions and refuses to overwrite an existing file unless you pass --force explicitly.
An injected file contains plaintext. Keep it out of version control, restrict access to it, and remove it when the consuming tool no longer needs it. Writing to stdout can also expose plaintext in terminal logs.

​
Inspect one reference

Use dry-run to verify its source without revealing the value:
Run without --dry-run only when you intentionally need plaintext on stdout. Avoid --json in logs for non-dry-run secret commands.

​
Reuse or detach a Vault

Attaching makes one shared key set available through another Project:
A later write to that Vault changes the value for every attached Project. Detach one Project without deleting keys:
Deleting a key from a Vault attached to multiple Projects affects every one of them, so the CLI refuses the operation unless you confirm the global effect.
Sharing a Project also gives its Viewers CLI runtime access to Vault values available through that Project. Review attachments before creating an invite or share link. See Projects and sharing.
Run clawdi vault --help, clawdi read --help, clawdi run --help, and clawdi inject --help for version-specific scope and conflict options.
Last modified on October 3, 2026