Using Vault

If you already run HashiCorp Vault, keep tokens there and only references in your setup.

When to use it

The default (a secrets.json encrypted with your passphrase) needs no server. If you already run Vault, keeping tokens in Vault KV v2 is better:

• Change a token in Vault and the next MCP server start uses it, without touching the repo or other machines.
• Access and audit go through your Vault policies.

Set up

aisync vault login --addr https://vault.example.com

Asks for a Vault token, checks it and stores it in the keychain. VAULT_TOKEN is used if set. The token needs read access to the paths you use, and write access if capture should move tokens there.

Move tokens to Vault on capture

aisync capture default --vault claude/aisync

Tokens found in MCP servers go to claude/aisync/<server>-<key> (KV v2 mount claude) in the value field, and the setup keeps a reference:

"SLACK_BOT_TOKEN": "{{vault:claude/aisync/slack-slack_bot_token#value}}"

You can write references by hand as {{vault:<mount>/<path>#<field>}}; the field defaults to value.

On other machines

aisync vault login --addr https://vault.example.com
aisync pull default

A machine not logged in to Vault stops at pull and says what's missing. After the pull, aisync reads the value from Vault every time Claude Code starts the server.

Verified behaviour

Checked against a real Vault (1.18):

• capture puts tokens in Vault and leaves only references in the repo
• another machine's pull is refused until it logs in to Vault
• after the pull, aisync exec, aisync headers and a real claude mcp list hand the Vault value to the servers
• changing only the value in Vault takes effect on the next server start, without a pull

Any Vault works, within these limits

You choose the server with --addr, so a Vault you run yourself works. This version requires:

Give the token a policy that allows only the paths it needs. A root token in your setup opens all of Vault if that machine is compromised.

These docs describe aisync 0.1.