{"id":"4d2458b5-84d3-41a2-86b9-b6440d2a4bbe","entityType":"agent","slug":"clawhub-snoweman-wundervault-vault","name":"Wundervault Vault","canonicalUrl":"https://www.xpersona.co/agent/clawhub-snoweman-wundervault-vault","canonicalPath":"/agent/clawhub-snoweman-wundervault-vault","generatedAt":"2026-10-10T02:03:03.040Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T20:07:34.066Z","emptyReason":null},"description":"Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — wit...","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 2K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s17c1yjaae9xr2br7s67vews6x85s6xf:wundervault-vault","sourceUrl":"https://clawhub.ai/snoweman/wundervault-vault","homepage":"https://clawhub.ai/snoweman/skills/wundervault-vault","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/snoweman/wundervault-vault","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/snoweman/skills/wundervault-vault","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":66,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Wundervault Vault technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T20:07:34.066Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T20:07:34.066Z","emptyReason":null},"stars":null,"forks":null,"downloads":2041,"packageName":null,"latestVersion":"1.6.9","tractionLabel":"2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T20:07:34.066Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T20:07:34.066Z","lastCrawledAt":"2026-10-09T20:07:34.066Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T20:07:34.066Z","lastVerifiedAt":null,"highlights":[{"version":"1.6.9","createdAt":"2026-07-13T19:43:28.069Z","changelog":"Tier-2 scoped approvals wording + x402 agent-wallet signing pattern","fileCount":4,"zipByteSize":7257},{"version":"1.6.4","createdAt":"2026-07-10T16:51:28.787Z","changelog":"Security Notes now link the self-serve zero-knowledge verification guide at wundervault.com/verify","fileCount":4,"zipByteSize":6893},{"version":"1.6.3","createdAt":"2026-06-12T04:16:31.011Z","changelog":"Document the file-write/redirect block and the new SSH-only vault_exec (entry_id optional, MCP v1.6.6).","fileCount":4,"zipByteSize":6777},{"version":"1.6.2","createdAt":"2026-05-16T19:34:24.950Z","changelog":"Removed vault_http_post — outbound exfiltration risk. Idea preserved for future work with proper allowlist design.","fileCount":4,"zipByteSize":6512},{"version":"1.6.0","createdAt":"2026-05-16T17:45:44.834Z","changelog":"Added vault_http_post: zero-knowledge HTTP requests with vault secrets injected into headers","fileCount":3,"zipByteSize":5686},{"version":"1.5.12","createdAt":"2026-05-14T17:41:40.936Z","changelog":"v1.5.12: Add first-run onboarding flow — vault_entries_list now drives setup state detection with contact form link, account setup guidance, and /verify page reference.","fileCount":3,"zipByteSize":5256},{"version":"1.5.11","createdAt":"2026-05-14T05:00:24.989Z","changelog":"v1.5.11: Pipe mode documented as hard-blocked. Link to /verify page for checksum and signature. Multi-agent section, revocation note, daemon architecture (ASI03), opt-in env injection (ASI09) added to security notes.","fileCount":3,"zipByteSize":4933},{"version":"1.5.10","createdAt":"2026-05-14T04:33:59.128Z","changelog":"v1.5.10: vault_entry_inject_env is now disabled by default and requires explicit opt-in via dashboard (CIP-021). Added multi-agent setup documentation. Updated security notes to reflect daemon architecture and per-agent credential isolation.","fileCount":3,"zipByteSize":4593}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17c1yjaae9xr2br7s67vews6x85s6xf:wundervault-vault","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s17c1yjaae9xr2br7s67vews6x85s6xf:wundervault-vault` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/snoweman/wundervault-vault before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-snoweman-wundervault-vault/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-snoweman-wundervault-vault/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-snoweman-wundervault-vault/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-snoweman-wundervault-vault/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-snoweman-wundervault-vault/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-snoweman-wundervault-vault/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T02:03:03.037Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-snoweman-wundervault-vault/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-snoweman-wundervault-vault/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-snoweman-wundervault-vault/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-snoweman-wundervault-vault/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T20:07:34.066Z","emptyReason":null},"readme":"Skill: Wundervault Vault\n\nOwner: snoweman\n\nSummary: Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — wit...\n\nTags: api-keys:1.0.1, credentials:1.0.1, latest:1.6.9, mcp:1.5.8, passwords:1.0.1, secrets:1.5.8, security:1.5.8, self-hosted:1.0.1, vault:1.5.8\n\nVersion history:\n\nv1.6.9 | 2026-07-13T19:43:28.069Z | user\n\nTier-2 scoped approvals wording + x402 agent-wallet signing pattern\n\nv1.6.4 | 2026-07-10T16:51:28.787Z | user\n\nSecurity Notes now link the self-serve zero-knowledge verification guide at wundervault.com/verify\n\nv1.6.3 | 2026-06-12T04:16:31.011Z | user\n\nDocument the file-write/redirect block and the new SSH-only vault_exec (entry_id optional, MCP v1.6.6).\n\nv1.6.2 | 2026-05-16T19:34:24.950Z | user\n\nRemoved vault_http_post — outbound exfiltration risk. Idea preserved for future work with proper allowlist design.\n\nv1.6.0 | 2026-05-16T17:45:44.834Z | user\n\nAdded vault_http_post: zero-knowledge HTTP requests with vault secrets injected into headers\n\nv1.5.12 | 2026-05-14T17:41:40.936Z | user\n\nv1.5.12: Add first-run onboarding flow — vault_entries_list now drives setup state detection with contact form link, account setup guidance, and /verify page reference.\n\nv1.5.11 | 2026-05-14T05:00:24.989Z | user\n\nv1.5.11: Pipe mode documented as hard-blocked. Link to /verify page for checksum and signature. Multi-agent section, revocation note, daemon architecture (ASI03), opt-in env injection (ASI09) added to security notes.\n\nv1.5.10 | 2026-05-14T04:33:59.128Z | user\n\nv1.5.10: vault_entry_inject_env is now disabled by default and requires explicit opt-in via dashboard (CIP-021). Added multi-agent setup documentation. Updated security notes to reflect daemon architecture and per-agent credential isolation.\n\nv1.5.9 | 2026-05-13T19:48:32.076Z | user\n\n▎ Clarify that Wundervault is a hosted service (invite-only at\n ▎ wundervault.com/contact). Add pinned versioned onboarding script URL with\n ▎ SHA-256 checksum verification (ASI04). Add WV_SETUP_URL env var support to\n ▎ keep setup passphrase out of shell history (ASI03). Recommend Tier 2 for\n ▎ high-impact secrets (ASI02). Clarify MCP tool response non-exposure scope\n ▎ (ASI09). Remove deprecated vault_session_status and vault_session_unlock\n ▎ tools.\n\nv1.5.8 | 2026-05-13T03:22:25.990Z | user\n\nRemove session lock tools (vault_session_status, vault_session_unlock). Add vault_rsync. Tier 2 now enabled via wundervault.com dashboard.\n\nv1.4.0 | 2026-05-07T21:26:18.705Z | user\n\nFix vault_entry_get description (does not return plaintext), fix vault_entry_inject_env parameter names, add vault_rsync tool\n\nv1.3.0 | 2026-05-05T16:43:02.906Z | user\n\nAdd ssh_key_entry_id: SSH key fetched from vault, never written to disk or exposed to agent\n\nv1.2.1 | 2026-05-05T15:16:03.057Z | user\n\nFix: use double quotes around env var in remote curl command so remote shell expands the variable\n\nv1.2.0 | 2026-05-05T14:13:44.433Z | user\n\nvault_exec remote_host: inject secrets into SSH remote commands without AcceptEnv config\n\nv1.1.0 | 2026-04-30T21:01:10.927Z | user\n\nFix tool names (vault_entry_get/vault_entries_list); update INSTALL.md to use onboard.py + WUNDERVAULT_CREDENTIALS_FILE; add multi-agent setup docs\n\nv1.0.3 | 2026-04-29T15:27:10.888Z | user\n\nDirect link to contact form for invite requests\n\nv1.0.2 | 2026-04-29T15:26:08.749Z | user\n\nUpdated install instructions — request access via contact form at wundervault.com\n\nv1.0.1 | 2026-04-29T14:55:30.940Z | user\n\nImproved description for discoverability — added password, API key, credentials, MCP terms\n\nv1.0.0 | 2026-04-29T14:53:38.068Z | user\n\nInitial release — MCP-based secret vault access for OpenClaw agents\n\nArchive index:\n\nArchive v1.6.9: 4 files, 7257 bytes\n\nFiles: _meta.json (136b), INSTALL.md (2587b), skill-card.md (2639b), SKILL.md (10569b)\n\nFile v1.6.9:SKILL.md\n\n---\nname: wundervault-vault\ndescription: Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — without exposing them in chat. Requires a Wundervault account — request early access at wundervault.com.\n---\n\n# Wundervault Vault\n\nWundervault is an encrypted, self-hosted secret vault that exposes secrets to agents via MCP tools. Secrets never appear in chat — they are decrypted server-side and injected directly into commands or written to config files. **The plaintext of a secret is never returned to the agent.**\n\n## Check Setup First\n\nAlways call `vault_entries_list` before doing anything vault-related. Use the result to determine where the user is in setup:\n\n| Result | What it means | What to do |\n|--------|--------------|------------|\n| Returns a list of entries | Vault is connected and ready | Proceed |\n| Returns empty list | Connected but no secrets yet | Tell the user to add secrets at wundervault.com |\n| Returns auth/credentials error | MCP server installed but not onboarded | Walk through onboarding (see below) |\n| Tool not available | MCP server not wired to this agent | Walk through setup (see INSTALL.md) |\n\n### First-run onboarding\n\nIf the vault tools are missing or credentials are invalid, tell the user:\n\n> \"Wundervault isn't set up yet. Here's how to get started:\n> 1. Request access via the [contact form](https://wundervault.com/contact)\n> 2. Once approved, set up your account and onboard your agent at wundervault.com\n> 3. Verify the MCP server package using the checksums at [wundervault.com/install](https://wundervault.com/install)\n> 4. Come back and I'll verify the connection\"\n\nDo not attempt to use any vault tools until `vault_entries_list` succeeds.\n\n## Tools\n\n### `vault_entries_list`\nList all vault entries available to this agent. Returns entry IDs and names only — no secret values.\n\n```\nvault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]\n```\n\nUse this first to get the entry ID before calling any other tool.\n\n### `vault_entry_get`\nRetrieve and burn a secret. The secret is decrypted server-side and **never returned to the agent** — you will receive a burn confirmation only.\n\n```\nvault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\"\n```\n\nUse this only to confirm a secret exists or to acknowledge retrieval. To actually use a secret in a command or file, use `vault_exec` or `vault_entry_inject_env` instead.\n\n### `vault_exec`\nExecute a shell command with a vault secret injected as an environment variable — the secret is never exposed in chat or logs.\n\n```\nvault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")\n```\n\n**Two tiers:**\n- **Tier 1** (standard): runs immediately\n- **Tier 2** (restricted): the call is denied until the owner approves. The denial carries a request id and the owner is emailed automatically; approval is scoped to this agent + secret (single-use, or a 15/60-minute window). Retry after approval — do not treat the denial as an error.\n\nShell escape sequences (`$()`, backticks, `bash -c`, `eval`) and file-writing redirects (`>`, `>>`, `tee`) are hard-blocked before the secret is decrypted. To put a secret into a file, use `vault_entry_inject_env` — do not redirect it with the shell. (These blocks are a guardrail, not a sandbox; the real protection is that plaintext is never returned to you.)\n\n**Remote execution via SSH:** Pass `remote_host` to run the command on a remote machine. The secret is injected inside the remote shell via SSH stdin — no `AcceptEnv`/`SendEnv` config required on the remote host. Use `ssh_key_entry_id` to load the SSH key from the vault itself.\n\n```\nvault_exec(\n entry_id: \"abc123\",\n purpose: \"check subscribers on prod\",\n command: \"curl -s -u \\\"admin:$DB_PASSWORD\\\" http://localhost:9000/api/subscribers\",\n inject_as: { env_key: \"DB_PASSWORD\" },\n remote_host: { host: \"192.168.1.50\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n**Remote command with only an SSH key (no secret injected):** `entry_id` is optional. To run a command on a remote host using just a vaulted SSH key — without injecting any secret as an env var — omit `entry_id` and pass `remote_host.ssh_key_entry_id`.\n\n```\nvault_exec(\n purpose: \"restart the service on prod\",\n command: \"sudo systemctl restart wundervault\",\n remote_host: { host: \"prod.example.com\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n### `vault_entry_inject_env`\nWrite a secret directly into an environment file (`.env`) as an environment variable, without it passing through chat.\n\n**Disabled by default.** To use this tool, enable it in Settings > Agent Capabilities at wundervault.com. You can disable it again at any time.\n\n```\nvault_entry_inject_env(\n entry_id: \"abc123\",\n purpose: \"inject API key into app config\",\n file_path: \"/home/user/app/.env\",\n env_key: \"RESEND_API_KEY\"\n)\n```\n\nNote: `file_path` and `env_key` are the correct parameter names.\n\n**Why you'd enable it:** Writing secrets directly to `.env` files is the standard way to configure apps, containers, and deploy pipelines. Without this tool, you'd need to paste secrets manually — exposing them in your terminal or chat history. `vault_entry_inject_env` lets agents wire up credentials automatically while keeping plaintext out of the conversation entirely.\n\n**Risks to understand before enabling:**\n- An agent can write a secret to any `.env` path it can reach — including paths outside your project directory\n- If an agent is compromised or acting on a malicious prompt, it could inject credentials into unexpected locations\n- Written secrets are no longer burn-on-read — they persist on disk in the target file\n- File permissions on the `.env` are your responsibility; the tool writes the value but does not set restrictive permissions automatically\n\n### `vault_rsync`\nSync a local directory to a remote host via rsync over SSH, with the SSH key fetched from the vault. The key is written to a temp file for the transfer duration and deleted immediately after.\n\n```\nvault_rsync(\n ssh_key_entry_id: \"ssh-key-entry-id\",\n purpose: \"deploy static files to prod\",\n local_path: \"/home/user/app/dist/\",\n remote_user: \"opc\",\n remote_host: \"prod.example.com\",\n remote_path: \"/var/www/html\"\n)\n```\n\n### `vault_entry_forget`\nDiscard a vault entry reference from context. Does not delete the vault entry.\n\n```\nvault_entry_forget(entry_id: \"abc123\")\n→ ✔️ Reference discarded.\n```\n\n## Common Patterns\n\n**Run a command with a secret (Tier 1):**\n```\n1. vault_entries_list() → find entry ID for the secret you need\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\n\n**Run a command with a Tier 2 entry (deploy, publish, infrastructure change):**\n```\n1. vault_entries_list() → find entry ID\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\nNote: Tier 2 calls are denied until the owner approves from the wundervault.com dashboard — the owner is emailed automatically and the denial includes a request id. Retry after approval.\n\n**Sign an x402 payment with a vaulted wallet key (you never see the key):**\n```\n1. vault_entries_list() → find the wallet key entry (keep wallet keys at Tier 2)\n2. vault_exec(entry_id: \"...\", purpose: \"sign x402 payment for \", command: \"node sign-payment.mjs\", inject_as: { env_key: \"X402_WALLET_KEY\" })\n3. Denied with a request id? The owner has been emailed — retry after they approve.\n```\nThe signing script reads the key from its environment and prints only the signed `X-PAYMENT` header. A verified end-to-end run (402 → approval → signed → settled on Base Sepolia) is at [wundervault.com/agent-wallets](https://wundervault.com/agent-wallets).\n\n**Write a secret to a config file:**\n```\n1. vault_entries_list() → find entry ID\n2. vault_entry_inject_env(entry_id: \"abc123\", purpose: \"...\", file_path: \"/app/.env\", env_key: \"MY_KEY\")\n```\n\n**Deploy files to a remote server:**\n```\n1. vault_entries_list() → find SSH key entry ID\n2. vault_rsync(ssh_key_entry_id: \"...\", local_path: \"./dist/\", remote_user: \"opc\", remote_host: \"prod.example.com\", remote_path: \"/var/www/html\")\n```\n\n\n## Multi-Agent Setup\n\nWundervault is designed for multi-agent environments. Each agent gets its own scoped identity and token — they are fully isolated from each other at the daemon level.\n\n- Each agent authenticates with its own token file (`~/.wundervault/agents/{AgentName}.token`)\n- Agents can only access entries they have been explicitly granted\n- The vault owner controls which agents exist and what they can reach from the wundervault.com dashboard\n- Agents cannot see each other's tokens, identities, or access scopes\n- Audit logs are per-agent, so you can trace exactly which agent accessed which secret and when\n\nThis makes Wundervault suitable for setups where multiple specialized agents (a coding agent, a deploy agent, a partner agent, etc.) share infrastructure but must not share credentials.\n\n## Security Notes\n\n- Secrets are end-to-end encrypted; plaintext is never returned to the agent\n- The zero-knowledge claim is independently verifiable — no source access needed: [wundervault.com/verify](https://wundervault.com/verify) (browser DevTools walkthrough or mitmproxy canary test, with a published transcript)\n- The onboarding script verifies its own ed25519 signature on startup and exits if the check fails. Pipe mode (`curl ... | python3`) is hard-blocked — the script detects it and refuses to run. Pinned version, SHA-256 checksum, and public key are at [wundervault.com/install](https://wundervault.com/install).\n- Agents never hold credentials directly — only a scoped token is stored locally. The local daemon manages the actual credentials and exposes them only through its controlled interface, enforcing tier checks and audit logging on every request. Compromise of an agent token does not grant direct access to vault credentials.\n- `vault_exec` and `vault_rsync` are the correct tools for using secrets — not `vault_entry_get`\n- Tier 2 entries are configured by the vault owner; agents cannot escalate a Tier 1 entry\n- Tier 2 access is enabled server-side by the user via the wundervault.com dashboard\n- The `inject_as` override lets you specify which env var name receives the secret if the vault entry has no exec_config set\n\n## More Info\n\n- npm: `@wundervault/mcp-server`\n- Vault UI: [wundervault.com](https://wundervault.com)\n\nFile v1.6.9:_meta.json\n\n{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.6.9\",\n \"publishedAt\": 1783971808069\n}\n\nFile v1.6.9:INSTALL.md\n\n# Installing Wundervault Vault\n\n## Prerequisites\n\n- A Wundervault account — request early access via the [contact form](https://wundervault.com/contact)\n- An agent configured in your Wundervault dashboard (Settings → Agents)\n- Node.js / npm installed\n\n## Step 1 — Install the MCP server\n\n```bash\nnpm install -g @wundervault/mcp-server\n```\n\nOr install locally in your OpenClaw workspace:\n\n```bash\ncd ~/.openclaw/workspace\nnpm install @wundervault/mcp-server\n```\n\n## Step 2 — Run the onboarding script\n\nIn your Wundervault dashboard under **Settings → Agents**, create an agent and copy the setup URL (it includes the passphrase in the `#fragment`). Download the script, then run it:\n\n```bash\ncurl -fsSL https://wundervault.com/onboard -o /tmp/wv-onboard.py\npython3 /tmp/wv-onboard.py \"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\"\n```\n\nThe script must be downloaded before running — pipe mode (`curl ... | python3`) is blocked. The script verifies its own ed25519 signature on startup and exits immediately if the check fails.\n\nPinned version, SHA-256 checksum, and the ed25519 public key for independent verification are available at [wundervault.com/install](https://wundervault.com/install).\n\nThe script will:\n- Verify its own signature before doing anything else\n- Decrypt your credentials locally (passphrase never sent to the server)\n- Save them to `~/.wundervault/creds-{agent_name}.json`\n- Auto-configure OpenClaw (`~/.openclaw/openclaw.json`) if present\n- Clear any stale MCP session so the new credentials take effect immediately\n\n## Multiple agents on the same machine\n\nEach agent gets its own named credentials file (`~/.wundervault/creds-Byte.json`, `~/.wundervault/creds-Claude.json`, etc.). The onboarding script handles this automatically for OpenClaw.\n\nFor other clients (Claude Code, Cursor, Windsurf), set this env var in their MCP config to point at the right file:\n\n```json\n{\n \"mcpServers\": {\n \"wundervault\": {\n \"command\": \"wundervault-mcp\",\n \"env\": {\n \"WUNDERVAULT_CREDENTIALS_FILE\": \"/home/youruser/.wundervault/creds-Claude.json\"\n }\n }\n }\n}\n```\n\nCommon global MCP config locations:\n- **Claude Code**: `~/.claude/mcp.json`\n- **Cursor**: `~/.cursor/mcp.json`\n- **Windsurf**: `~/.codeium/windsurf/mcp_config.json`\n\n## Verify\n\nAsk your agent:\n\n> \"List my vault secrets\"\n\nThe agent should call `vault_entries_list` and show available entries.\n\n## Self-Hosting\n\nWundervault is open-source and can be self-hosted. The onboarding script auto-detects the vault URL from the setup link, so no extra configuration is needed.\n\nFile v1.6.9:skill-card.md\n\n## Description:\n\nRead passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected without exposing secret values in chat.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[snoweman](https://clawhub.ai/user/snoweman)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and agent operators use this skill to connect agents to Wundervault, list scoped vault entries, and run approved commands or configuration updates with secrets injected outside the chat transcript.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Installing or onboarding the MCP server for real secrets can expose high-value credentials if the package or onboarding script is not reviewed first.\n\nMitigation: Verify pinned package versions, checksums, and the onboarding script before installation, and review the skill before granting secrets, SSH keys, deployment authority, wallet keys, or .env write access.\n\nRisk: Secret injection into .env files can persist credentials on disk or write them to unexpected paths.\n\nMitigation: Keep .env injection disabled unless needed, restrict each agent to necessary vault entries and command authority, and review target paths and file permissions before enabling it.\n\nRisk: Commands run with injected secrets can affect deployment, publishing, infrastructure, or wallet-signing workflows.\n\nMitigation: Use scoped vault entries, approval for sensitive entries, purpose strings, and audit review before retrying denied operations.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/snoweman/skills/wundervault-vault)\n- [Wundervault install verification](https://wundervault.com/install)\n- [Wundervault zero-knowledge verification](https://wundervault.com/verify)\n- [Wundervault agent wallets](https://wundervault.com/agent-wallets)\n- [Wundervault](https://wundervault.com)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Shell commands, Configuration]\n\n**Output Format:** [Markdown with inline code blocks and MCP tool-call examples]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Agent-facing output should reference vault entries and actions without returning plaintext secret values.]\n\n## Skill Version(s):\n\n1.6.9 (source: server release metadata and artifact metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.6.4: 4 files, 6893 bytes\n\nFiles: _meta.json (136b), INSTALL.md (2587b), skill-card.md (2700b), SKILL.md (9655b)\n\nFile v1.6.4:SKILL.md\n\n---\nname: wundervault-vault\ndescription: Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — without exposing them in chat. Requires a Wundervault account — request early access at wundervault.com.\n---\n\n# Wundervault Vault\n\nWundervault is an encrypted, self-hosted secret vault that exposes secrets to agents via MCP tools. Secrets never appear in chat — they are decrypted server-side and injected directly into commands or written to config files. **The plaintext of a secret is never returned to the agent.**\n\n## Check Setup First\n\nAlways call `vault_entries_list` before doing anything vault-related. Use the result to determine where the user is in setup:\n\n| Result | What it means | What to do |\n|--------|--------------|------------|\n| Returns a list of entries | Vault is connected and ready | Proceed |\n| Returns empty list | Connected but no secrets yet | Tell the user to add secrets at wundervault.com |\n| Returns auth/credentials error | MCP server installed but not onboarded | Walk through onboarding (see below) |\n| Tool not available | MCP server not wired to this agent | Walk through setup (see INSTALL.md) |\n\n### First-run onboarding\n\nIf the vault tools are missing or credentials are invalid, tell the user:\n\n> \"Wundervault isn't set up yet. Here's how to get started:\n> 1. Request access via the [contact form](https://wundervault.com/contact)\n> 2. Once approved, set up your account and onboard your agent at wundervault.com\n> 3. Verify the MCP server package using the checksums at [wundervault.com/install](https://wundervault.com/install)\n> 4. Come back and I'll verify the connection\"\n\nDo not attempt to use any vault tools until `vault_entries_list` succeeds.\n\n## Tools\n\n### `vault_entries_list`\nList all vault entries available to this agent. Returns entry IDs and names only — no secret values.\n\n```\nvault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]\n```\n\nUse this first to get the entry ID before calling any other tool.\n\n### `vault_entry_get`\nRetrieve and burn a secret. The secret is decrypted server-side and **never returned to the agent** — you will receive a burn confirmation only.\n\n```\nvault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\"\n```\n\nUse this only to confirm a secret exists or to acknowledge retrieval. To actually use a secret in a command or file, use `vault_exec` or `vault_entry_inject_env` instead.\n\n### `vault_exec`\nExecute a shell command with a vault secret injected as an environment variable — the secret is never exposed in chat or logs.\n\n```\nvault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")\n```\n\n**Two tiers:**\n- **Tier 1** (standard): runs immediately\n- **Tier 2** (restricted): Tier 2 access is controlled server-side — the user enables it from the wundervault.com dashboard\n\nShell escape sequences (`$()`, backticks, `bash -c`, `eval`) and file-writing redirects (`>`, `>>`, `tee`) are hard-blocked before the secret is decrypted. To put a secret into a file, use `vault_entry_inject_env` — do not redirect it with the shell. (These blocks are a guardrail, not a sandbox; the real protection is that plaintext is never returned to you.)\n\n**Remote execution via SSH:** Pass `remote_host` to run the command on a remote machine. The secret is injected inside the remote shell via SSH stdin — no `AcceptEnv`/`SendEnv` config required on the remote host. Use `ssh_key_entry_id` to load the SSH key from the vault itself.\n\n```\nvault_exec(\n entry_id: \"abc123\",\n purpose: \"check subscribers on prod\",\n command: \"curl -s -u \\\"admin:$DB_PASSWORD\\\" http://localhost:9000/api/subscribers\",\n inject_as: { env_key: \"DB_PASSWORD\" },\n remote_host: { host: \"192.168.1.50\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n**Remote command with only an SSH key (no secret injected):** `entry_id` is optional. To run a command on a remote host using just a vaulted SSH key — without injecting any secret as an env var — omit `entry_id` and pass `remote_host.ssh_key_entry_id`.\n\n```\nvault_exec(\n purpose: \"restart the service on prod\",\n command: \"sudo systemctl restart wundervault\",\n remote_host: { host: \"prod.example.com\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n### `vault_entry_inject_env`\nWrite a secret directly into an environment file (`.env`) as an environment variable, without it passing through chat.\n\n**Disabled by default.** To use this tool, enable it in Settings > Agent Capabilities at wundervault.com. You can disable it again at any time.\n\n```\nvault_entry_inject_env(\n entry_id: \"abc123\",\n purpose: \"inject API key into app config\",\n file_path: \"/home/user/app/.env\",\n env_key: \"RESEND_API_KEY\"\n)\n```\n\nNote: `file_path` and `env_key` are the correct parameter names.\n\n**Why you'd enable it:** Writing secrets directly to `.env` files is the standard way to configure apps, containers, and deploy pipelines. Without this tool, you'd need to paste secrets manually — exposing them in your terminal or chat history. `vault_entry_inject_env` lets agents wire up credentials automatically while keeping plaintext out of the conversation entirely.\n\n**Risks to understand before enabling:**\n- An agent can write a secret to any `.env` path it can reach — including paths outside your project directory\n- If an agent is compromised or acting on a malicious prompt, it could inject credentials into unexpected locations\n- Written secrets are no longer burn-on-read — they persist on disk in the target file\n- File permissions on the `.env` are your responsibility; the tool writes the value but does not set restrictive permissions automatically\n\n### `vault_rsync`\nSync a local directory to a remote host via rsync over SSH, with the SSH key fetched from the vault. The key is written to a temp file for the transfer duration and deleted immediately after.\n\n```\nvault_rsync(\n ssh_key_entry_id: \"ssh-key-entry-id\",\n purpose: \"deploy static files to prod\",\n local_path: \"/home/user/app/dist/\",\n remote_user: \"opc\",\n remote_host: \"prod.example.com\",\n remote_path: \"/var/www/html\"\n)\n```\n\n### `vault_entry_forget`\nDiscard a vault entry reference from context. Does not delete the vault entry.\n\n```\nvault_entry_forget(entry_id: \"abc123\")\n→ ✔️ Reference discarded.\n```\n\n## Common Patterns\n\n**Run a command with a secret (Tier 1):**\n```\n1. vault_entries_list() → find entry ID for the secret you need\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\n\n**Run a command with a Tier 2 entry (deploy, publish, infrastructure change):**\n```\n1. vault_entries_list() → find entry ID\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\nNote: Tier 2 entries require the user to enable access from the wundervault.com dashboard before use.\n\n**Write a secret to a config file:**\n```\n1. vault_entries_list() → find entry ID\n2. vault_entry_inject_env(entry_id: \"abc123\", purpose: \"...\", file_path: \"/app/.env\", env_key: \"MY_KEY\")\n```\n\n**Deploy files to a remote server:**\n```\n1. vault_entries_list() → find SSH key entry ID\n2. vault_rsync(ssh_key_entry_id: \"...\", local_path: \"./dist/\", remote_user: \"opc\", remote_host: \"prod.example.com\", remote_path: \"/var/www/html\")\n```\n\n\n## Multi-Agent Setup\n\nWundervault is designed for multi-agent environments. Each agent gets its own scoped identity and token — they are fully isolated from each other at the daemon level.\n\n- Each agent authenticates with its own token file (`~/.wundervault/agents/{AgentName}.token`)\n- Agents can only access entries they have been explicitly granted\n- The vault owner controls which agents exist and what they can reach from the wundervault.com dashboard\n- Agents cannot see each other's tokens, identities, or access scopes\n- Audit logs are per-agent, so you can trace exactly which agent accessed which secret and when\n\nThis makes Wundervault suitable for setups where multiple specialized agents (a coding agent, a deploy agent, a partner agent, etc.) share infrastructure but must not share credentials.\n\n## Security Notes\n\n- Secrets are end-to-end encrypted; plaintext is never returned to the agent\n- The zero-knowledge claim is independently verifiable — no source access needed: [wundervault.com/verify](https://wundervault.com/verify) (browser DevTools walkthrough or mitmproxy canary test, with a published transcript)\n- The onboarding script verifies its own ed25519 signature on startup and exits if the check fails. Pipe mode (`curl ... | python3`) is hard-blocked — the script detects it and refuses to run. Pinned version, SHA-256 checksum, and public key are at [wundervault.com/install](https://wundervault.com/install).\n- Agents never hold credentials directly — only a scoped token is stored locally. The local daemon manages the actual credentials and exposes them only through its controlled interface, enforcing tier checks and audit logging on every request. Compromise of an agent token does not grant direct access to vault credentials.\n- `vault_exec` and `vault_rsync` are the correct tools for using secrets — not `vault_entry_get`\n- Tier 2 entries are configured by the vault owner; agents cannot escalate a Tier 1 entry\n- Tier 2 access is enabled server-side by the user via the wundervault.com dashboard\n- The `inject_as` override lets you specify which env var name receives the secret if the vault entry has no exec_config set\n\n## More Info\n\n- npm: `@wundervault/mcp-server`\n- Vault UI: [wundervault.com](https://wundervault.com)\n\nFile v1.6.4:_meta.json\n\n{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.6.4\",\n \"publishedAt\": 1783702288787\n}\n\nFile v1.6.4:INSTALL.md\n\n# Installing Wundervault Vault\n\n## Prerequisites\n\n- A Wundervault account — request early access via the [contact form](https://wundervault.com/contact)\n- An agent configured in your Wundervault dashboard (Settings → Agents)\n- Node.js / npm installed\n\n## Step 1 — Install the MCP server\n\n```bash\nnpm install -g @wundervault/mcp-server\n```\n\nOr install locally in your OpenClaw workspace:\n\n```bash\ncd ~/.openclaw/workspace\nnpm install @wundervault/mcp-server\n```\n\n## Step 2 — Run the onboarding script\n\nIn your Wundervault dashboard under **Settings → Agents**, create an agent and copy the setup URL (it includes the passphrase in the `#fragment`). Download the script, then run it:\n\n```bash\ncurl -fsSL https://wundervault.com/onboard -o /tmp/wv-onboard.py\npython3 /tmp/wv-onboard.py \"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\"\n```\n\nThe script must be downloaded before running — pipe mode (`curl ... | python3`) is blocked. The script verifies its own ed25519 signature on startup and exits immediately if the check fails.\n\nPinned version, SHA-256 checksum, and the ed25519 public key for independent verification are available at [wundervault.com/install](https://wundervault.com/install).\n\nThe script will:\n- Verify its own signature before doing anything else\n- Decrypt your credentials locally (passphrase never sent to the server)\n- Save them to `~/.wundervault/creds-{agent_name}.json`\n- Auto-configure OpenClaw (`~/.openclaw/openclaw.json`) if present\n- Clear any stale MCP session so the new credentials take effect immediately\n\n## Multiple agents on the same machine\n\nEach agent gets its own named credentials file (`~/.wundervault/creds-Byte.json`, `~/.wundervault/creds-Claude.json`, etc.). The onboarding script handles this automatically for OpenClaw.\n\nFor other clients (Claude Code, Cursor, Windsurf), set this env var in their MCP config to point at the right file:\n\n```json\n{\n \"mcpServers\": {\n \"wundervault\": {\n \"command\": \"wundervault-mcp\",\n \"env\": {\n \"WUNDERVAULT_CREDENTIALS_FILE\": \"/home/youruser/.wundervault/creds-Claude.json\"\n }\n }\n }\n}\n```\n\nCommon global MCP config locations:\n- **Claude Code**: `~/.claude/mcp.json`\n- **Cursor**: `~/.cursor/mcp.json`\n- **Windsurf**: `~/.codeium/windsurf/mcp_config.json`\n\n## Verify\n\nAsk your agent:\n\n> \"List my vault secrets\"\n\nThe agent should call `vault_entries_list` and show available entries.\n\n## Self-Hosting\n\nWundervault is open-source and can be self-hosted. The onboarding script auto-detects the vault URL from the setup link, so no extra configuration is needed.\n\nFile v1.6.4:skill-card.md\n\n## Description:
\nWundervault Vault helps agents read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault and run authorized shell commands with injected secrets without exposing plaintext in chat.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[snoweman](https://clawhub.ai/user/snoweman)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nExternal developers and teams use this skill to let coding and deployment agents access scoped Wundervault secrets, run authorized local or remote commands, sync files, and write configuration values without revealing plaintext in chat.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill can let an agent use Wundervault-managed credentials for commands, deployments, SSH, and config-file setup.
\nMitigation: Install only when this capability is intended, grant only the vault entries the agent needs, and review commands before secrets are used.
\nRisk: Optional environment-file injection can persist secrets on disk and can target paths the agent can reach.
\nMitigation: Keep environment-file injection disabled unless required, review target file paths, and apply appropriate file permissions after writing secrets.
\nRisk: Setup depends on the Wundervault MCP package and onboarding script.
\nMitigation: Verify the npm package and onboarding script checksums or signature before running setup.
\n\n\n## Reference(s):
\n- [Artifact Skill Definition](artifact/SKILL.md)
\n- [Artifact Installation Guide](artifact/INSTALL.md)
\n- [ClawHub Skill Page](https://clawhub.ai/snoweman/skills/wundervault-vault)
\n- [Wundervault Install](https://wundervault.com/install)
\n- [Wundervault Verification Guide](https://wundervault.com/verify)
\n- [Wundervault](https://wundervault.com)
\n\n\n## Skill Output:
\n**Output Type(s):** [guidance, shell commands, configuration]
\n**Output Format:** [Markdown with inline shell, JSON, and MCP tool-call examples]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Guides agents to use Wundervault MCP tools for credential-aware commands, remote execution, rsync deployments, and optional environment-file injection.]
\n\n## Skill Version(s):
\n1.6.4 (source: server release metadata and artifact _meta.json)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.6.3: 4 files, 6777 bytes\n\nFiles: _meta.json (136b), INSTALL.md (2587b), skill-card.md (2536b), SKILL.md (9429b)\n\nFile v1.6.3:SKILL.md\n\n---\nname: wundervault-vault\ndescription: Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — without exposing them in chat. Requires a Wundervault account — request early access at wundervault.com.\n---\n\n# Wundervault Vault\n\nWundervault is an encrypted, self-hosted secret vault that exposes secrets to agents via MCP tools. Secrets never appear in chat — they are decrypted server-side and injected directly into commands or written to config files. **The plaintext of a secret is never returned to the agent.**\n\n## Check Setup First\n\nAlways call `vault_entries_list` before doing anything vault-related. Use the result to determine where the user is in setup:\n\n| Result | What it means | What to do |\n|--------|--------------|------------|\n| Returns a list of entries | Vault is connected and ready | Proceed |\n| Returns empty list | Connected but no secrets yet | Tell the user to add secrets at wundervault.com |\n| Returns auth/credentials error | MCP server installed but not onboarded | Walk through onboarding (see below) |\n| Tool not available | MCP server not wired to this agent | Walk through setup (see INSTALL.md) |\n\n### First-run onboarding\n\nIf the vault tools are missing or credentials are invalid, tell the user:\n\n> \"Wundervault isn't set up yet. Here's how to get started:\n> 1. Request access via the [contact form](https://wundervault.com/contact)\n> 2. Once approved, set up your account and onboard your agent at wundervault.com\n> 3. Verify the MCP server package using the checksums at [wundervault.com/install](https://wundervault.com/install)\n> 4. Come back and I'll verify the connection\"\n\nDo not attempt to use any vault tools until `vault_entries_list` succeeds.\n\n## Tools\n\n### `vault_entries_list`\nList all vault entries available to this agent. Returns entry IDs and names only — no secret values.\n\n```\nvault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]\n```\n\nUse this first to get the entry ID before calling any other tool.\n\n### `vault_entry_get`\nRetrieve and burn a secret. The secret is decrypted server-side and **never returned to the agent** — you will receive a burn confirmation only.\n\n```\nvault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\"\n```\n\nUse this only to confirm a secret exists or to acknowledge retrieval. To actually use a secret in a command or file, use `vault_exec` or `vault_entry_inject_env` instead.\n\n### `vault_exec`\nExecute a shell command with a vault secret injected as an environment variable — the secret is never exposed in chat or logs.\n\n```\nvault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")\n```\n\n**Two tiers:**\n- **Tier 1** (standard): runs immediately\n- **Tier 2** (restricted): Tier 2 access is controlled server-side — the user enables it from the wundervault.com dashboard\n\nShell escape sequences (`$()`, backticks, `bash -c`, `eval`) and file-writing redirects (`>`, `>>`, `tee`) are hard-blocked before the secret is decrypted. To put a secret into a file, use `vault_entry_inject_env` — do not redirect it with the shell. (These blocks are a guardrail, not a sandbox; the real protection is that plaintext is never returned to you.)\n\n**Remote execution via SSH:** Pass `remote_host` to run the command on a remote machine. The secret is injected inside the remote shell via SSH stdin — no `AcceptEnv`/`SendEnv` config required on the remote host. Use `ssh_key_entry_id` to load the SSH key from the vault itself.\n\n```\nvault_exec(\n entry_id: \"abc123\",\n purpose: \"check subscribers on prod\",\n command: \"curl -s -u \\\"admin:$DB_PASSWORD\\\" http://localhost:9000/api/subscribers\",\n inject_as: { env_key: \"DB_PASSWORD\" },\n remote_host: { host: \"192.168.1.50\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n**Remote command with only an SSH key (no secret injected):** `entry_id` is optional. To run a command on a remote host using just a vaulted SSH key — without injecting any secret as an env var — omit `entry_id` and pass `remote_host.ssh_key_entry_id`.\n\n```\nvault_exec(\n purpose: \"restart the service on prod\",\n command: \"sudo systemctl restart wundervault\",\n remote_host: { host: \"prod.example.com\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n### `vault_entry_inject_env`\nWrite a secret directly into an environment file (`.env`) as an environment variable, without it passing through chat.\n\n**Disabled by default.** To use this tool, enable it in Settings > Agent Capabilities at wundervault.com. You can disable it again at any time.\n\n```\nvault_entry_inject_env(\n entry_id: \"abc123\",\n purpose: \"inject API key into app config\",\n file_path: \"/home/user/app/.env\",\n env_key: \"RESEND_API_KEY\"\n)\n```\n\nNote: `file_path` and `env_key` are the correct parameter names.\n\n**Why you'd enable it:** Writing secrets directly to `.env` files is the standard way to configure apps, containers, and deploy pipelines. Without this tool, you'd need to paste secrets manually — exposing them in your terminal or chat history. `vault_entry_inject_env` lets agents wire up credentials automatically while keeping plaintext out of the conversation entirely.\n\n**Risks to understand before enabling:**\n- An agent can write a secret to any `.env` path it can reach — including paths outside your project directory\n- If an agent is compromised or acting on a malicious prompt, it could inject credentials into unexpected locations\n- Written secrets are no longer burn-on-read — they persist on disk in the target file\n- File permissions on the `.env` are your responsibility; the tool writes the value but does not set restrictive permissions automatically\n\n### `vault_rsync`\nSync a local directory to a remote host via rsync over SSH, with the SSH key fetched from the vault. The key is written to a temp file for the transfer duration and deleted immediately after.\n\n```\nvault_rsync(\n ssh_key_entry_id: \"ssh-key-entry-id\",\n purpose: \"deploy static files to prod\",\n local_path: \"/home/user/app/dist/\",\n remote_user: \"opc\",\n remote_host: \"prod.example.com\",\n remote_path: \"/var/www/html\"\n)\n```\n\n### `vault_entry_forget`\nDiscard a vault entry reference from context. Does not delete the vault entry.\n\n```\nvault_entry_forget(entry_id: \"abc123\")\n→ ✔️ Reference discarded.\n```\n\n## Common Patterns\n\n**Run a command with a secret (Tier 1):**\n```\n1. vault_entries_list() → find entry ID for the secret you need\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\n\n**Run a command with a Tier 2 entry (deploy, publish, infrastructure change):**\n```\n1. vault_entries_list() → find entry ID\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\nNote: Tier 2 entries require the user to enable access from the wundervault.com dashboard before use.\n\n**Write a secret to a config file:**\n```\n1. vault_entries_list() → find entry ID\n2. vault_entry_inject_env(entry_id: \"abc123\", purpose: \"...\", file_path: \"/app/.env\", env_key: \"MY_KEY\")\n```\n\n**Deploy files to a remote server:**\n```\n1. vault_entries_list() → find SSH key entry ID\n2. vault_rsync(ssh_key_entry_id: \"...\", local_path: \"./dist/\", remote_user: \"opc\", remote_host: \"prod.example.com\", remote_path: \"/var/www/html\")\n```\n\n\n## Multi-Agent Setup\n\nWundervault is designed for multi-agent environments. Each agent gets its own scoped identity and token — they are fully isolated from each other at the daemon level.\n\n- Each agent authenticates with its own token file (`~/.wundervault/agents/{AgentName}.token`)\n- Agents can only access entries they have been explicitly granted\n- The vault owner controls which agents exist and what they can reach from the wundervault.com dashboard\n- Agents cannot see each other's tokens, identities, or access scopes\n- Audit logs are per-agent, so you can trace exactly which agent accessed which secret and when\n\nThis makes Wundervault suitable for setups where multiple specialized agents (a coding agent, a deploy agent, a partner agent, etc.) share infrastructure but must not share credentials.\n\n## Security Notes\n\n- Secrets are end-to-end encrypted; plaintext is never returned to the agent\n- The onboarding script verifies its own ed25519 signature on startup and exits if the check fails. Pipe mode (`curl ... | python3`) is hard-blocked — the script detects it and refuses to run. Pinned version, SHA-256 checksum, and public key are at [wundervault.com/install](https://wundervault.com/install).\n- Agents never hold credentials directly — only a scoped token is stored locally. The local daemon manages the actual credentials and exposes them only through its controlled interface, enforcing tier checks and audit logging on every request. Compromise of an agent token does not grant direct access to vault credentials.\n- `vault_exec` and `vault_rsync` are the correct tools for using secrets — not `vault_entry_get`\n- Tier 2 entries are configured by the vault owner; agents cannot escalate a Tier 1 entry\n- Tier 2 access is enabled server-side by the user via the wundervault.com dashboard\n- The `inject_as` override lets you specify which env var name receives the secret if the vault entry has no exec_config set\n\n## More Info\n\n- npm: `@wundervault/mcp-server`\n- Vault UI: [wundervault.com](https://wundervault.com)\n\nFile v1.6.3:_meta.json\n\n{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.6.3\",\n \"publishedAt\": 1781237791011\n}\n\nFile v1.6.3:INSTALL.md\n\n# Installing Wundervault Vault\n\n## Prerequisites\n\n- A Wundervault account — request early access via the [contact form](https://wundervault.com/contact)\n- An agent configured in your Wundervault dashboard (Settings → Agents)\n- Node.js / npm installed\n\n## Step 1 — Install the MCP server\n\n```bash\nnpm install -g @wundervault/mcp-server\n```\n\nOr install locally in your OpenClaw workspace:\n\n```bash\ncd ~/.openclaw/workspace\nnpm install @wundervault/mcp-server\n```\n\n## Step 2 — Run the onboarding script\n\nIn your Wundervault dashboard under **Settings → Agents**, create an agent and copy the setup URL (it includes the passphrase in the `#fragment`). Download the script, then run it:\n\n```bash\ncurl -fsSL https://wundervault.com/onboard -o /tmp/wv-onboard.py\npython3 /tmp/wv-onboard.py \"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\"\n```\n\nThe script must be downloaded before running — pipe mode (`curl ... | python3`) is blocked. The script verifies its own ed25519 signature on startup and exits immediately if the check fails.\n\nPinned version, SHA-256 checksum, and the ed25519 public key for independent verification are available at [wundervault.com/install](https://wundervault.com/install).\n\nThe script will:\n- Verify its own signature before doing anything else\n- Decrypt your credentials locally (passphrase never sent to the server)\n- Save them to `~/.wundervault/creds-{agent_name}.json`\n- Auto-configure OpenClaw (`~/.openclaw/openclaw.json`) if present\n- Clear any stale MCP session so the new credentials take effect immediately\n\n## Multiple agents on the same machine\n\nEach agent gets its own named credentials file (`~/.wundervault/creds-Byte.json`, `~/.wundervault/creds-Claude.json`, etc.). The onboarding script handles this automatically for OpenClaw.\n\nFor other clients (Claude Code, Cursor, Windsurf), set this env var in their MCP config to point at the right file:\n\n```json\n{\n \"mcpServers\": {\n \"wundervault\": {\n \"command\": \"wundervault-mcp\",\n \"env\": {\n \"WUNDERVAULT_CREDENTIALS_FILE\": \"/home/youruser/.wundervault/creds-Claude.json\"\n }\n }\n }\n}\n```\n\nCommon global MCP config locations:\n- **Claude Code**: `~/.claude/mcp.json`\n- **Cursor**: `~/.cursor/mcp.json`\n- **Windsurf**: `~/.codeium/windsurf/mcp_config.json`\n\n## Verify\n\nAsk your agent:\n\n> \"List my vault secrets\"\n\nThe agent should call `vault_entries_list` and show available entries.\n\n## Self-Hosting\n\nWundervault is open-source and can be self-hosted. The onboarding script auto-detects the vault URL from the setup link, so no extra configuration is needed.\n\nFile v1.6.3:skill-card.md\n\n## Description:
\nRead passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected without exposing them in chat.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[snoweman](https://clawhub.ai/user/snoweman)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and operators use this skill to connect an agent to Wundervault, list permitted vault entries, run authorized commands with scoped secrets injected, and write secrets to approved config files without exposing plaintext in chat.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill enables an agent to use scoped vault credentials for commands, configuration files, SSH, and deployment tasks.
\nMitigation: Install only when that access is intended, verify the npm package and onboarding script checksum or signature before setup, and keep vault grants least-privilege.
\nRisk: Environment-file injection can place secrets on disk where they persist outside burn-on-read vault workflows.
\nMitigation: Enable .env injection only for workflows where the impact is understood, review target paths, and manage file permissions for written secret files.
\nRisk: Tier 2 secrets and deployment actions can affect production systems if granted too broadly.
\nMitigation: Use server-side Tier 2 enablement only for approved workflows and limit each agent to the entries required for its task.
\n\n\n## Reference(s):
\n- [ClawHub Skill Page](https://clawhub.ai/snoweman/wundervault-vault)
\n- [Wundervault](https://wundervault.com)
\n- [Wundervault Install Verification](https://wundervault.com/install)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, shell commands, configuration, guidance]
\n**Output Format:** [Markdown guidance with inline tool-call examples, shell commands, and configuration snippets]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [May guide MCP tool calls that inject vaulted credentials without returning plaintext secrets.]
\n\n## Skill Version(s):
\n1.6.3 (source: server evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.6.2: 4 files, 6512 bytes\n\nFiles: _meta.json (136b), INSTALL.md (2587b), skill-card.md (2423b), SKILL.md (8708b)\n\nFile v1.6.2:SKILL.md\n\n---\nname: wundervault-vault\ndescription: Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — without exposing them in chat. Requires a Wundervault account — request early access at wundervault.com.\n---\n\n# Wundervault Vault\n\nWundervault is an encrypted, self-hosted secret vault that exposes secrets to agents via MCP tools. Secrets never appear in chat — they are decrypted server-side and injected directly into commands or written to config files. **The plaintext of a secret is never returned to the agent.**\n\n## Check Setup First\n\nAlways call `vault_entries_list` before doing anything vault-related. Use the result to determine where the user is in setup:\n\n| Result | What it means | What to do |\n|--------|--------------|------------|\n| Returns a list of entries | Vault is connected and ready | Proceed |\n| Returns empty list | Connected but no secrets yet | Tell the user to add secrets at wundervault.com |\n| Returns auth/credentials error | MCP server installed but not onboarded | Walk through onboarding (see below) |\n| Tool not available | MCP server not wired to this agent | Walk through setup (see INSTALL.md) |\n\n### First-run onboarding\n\nIf the vault tools are missing or credentials are invalid, tell the user:\n\n> \"Wundervault isn't set up yet. Here's how to get started:\n> 1. Request access via the [contact form](https://wundervault.com/contact)\n> 2. Once approved, set up your account and onboard your agent at wundervault.com\n> 3. Verify the MCP server package using the checksums at [wundervault.com/install](https://wundervault.com/install)\n> 4. Come back and I'll verify the connection\"\n\nDo not attempt to use any vault tools until `vault_entries_list` succeeds.\n\n## Tools\n\n### `vault_entries_list`\nList all vault entries available to this agent. Returns entry IDs and names only — no secret values.\n\n```\nvault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]\n```\n\nUse this first to get the entry ID before calling any other tool.\n\n### `vault_entry_get`\nRetrieve and burn a secret. The secret is decrypted server-side and **never returned to the agent** — you will receive a burn confirmation only.\n\n```\nvault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\"\n```\n\nUse this only to confirm a secret exists or to acknowledge retrieval. To actually use a secret in a command or file, use `vault_exec` or `vault_entry_inject_env` instead.\n\n### `vault_exec`\nExecute a shell command with a vault secret injected as an environment variable — the secret is never exposed in chat or logs.\n\n```\nvault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")\n```\n\n**Two tiers:**\n- **Tier 1** (standard): runs immediately\n- **Tier 2** (restricted): Tier 2 access is controlled server-side — the user enables it from the wundervault.com dashboard\n\nShell escape sequences (`$()`, backticks, `bash -c`, `eval`) are hard-blocked before the secret is decrypted.\n\n**Remote execution via SSH:** Pass `remote_host` to run the command on a remote machine. The secret is injected inside the remote shell via SSH stdin — no `AcceptEnv`/`SendEnv` config required on the remote host. Use `ssh_key_entry_id` to load the SSH key from the vault itself.\n\n```\nvault_exec(\n entry_id: \"abc123\",\n purpose: \"check subscribers on prod\",\n command: \"curl -s -u \\\"admin:$DB_PASSWORD\\\" http://localhost:9000/api/subscribers\",\n inject_as: { env_key: \"DB_PASSWORD\" },\n remote_host: { host: \"192.168.1.50\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n### `vault_entry_inject_env`\nWrite a secret directly into an environment file (`.env`) as an environment variable, without it passing through chat.\n\n**Disabled by default.** To use this tool, enable it in Settings > Agent Capabilities at wundervault.com. You can disable it again at any time.\n\n```\nvault_entry_inject_env(\n entry_id: \"abc123\",\n purpose: \"inject API key into app config\",\n file_path: \"/home/user/app/.env\",\n env_key: \"RESEND_API_KEY\"\n)\n```\n\nNote: `file_path` and `env_key` are the correct parameter names.\n\n**Why you'd enable it:** Writing secrets directly to `.env` files is the standard way to configure apps, containers, and deploy pipelines. Without this tool, you'd need to paste secrets manually — exposing them in your terminal or chat history. `vault_entry_inject_env` lets agents wire up credentials automatically while keeping plaintext out of the conversation entirely.\n\n**Risks to understand before enabling:**\n- An agent can write a secret to any `.env` path it can reach — including paths outside your project directory\n- If an agent is compromised or acting on a malicious prompt, it could inject credentials into unexpected locations\n- Written secrets are no longer burn-on-read — they persist on disk in the target file\n- File permissions on the `.env` are your responsibility; the tool writes the value but does not set restrictive permissions automatically\n\n### `vault_rsync`\nSync a local directory to a remote host via rsync over SSH, with the SSH key fetched from the vault. The key is written to a temp file for the transfer duration and deleted immediately after.\n\n```\nvault_rsync(\n ssh_key_entry_id: \"ssh-key-entry-id\",\n purpose: \"deploy static files to prod\",\n local_path: \"/home/user/app/dist/\",\n remote_user: \"opc\",\n remote_host: \"prod.example.com\",\n remote_path: \"/var/www/html\"\n)\n```\n\n### `vault_entry_forget`\nDiscard a vault entry reference from context. Does not delete the vault entry.\n\n```\nvault_entry_forget(entry_id: \"abc123\")\n→ ✔️ Reference discarded.\n```\n\n## Common Patterns\n\n**Run a command with a secret (Tier 1):**\n```\n1. vault_entries_list() → find entry ID for the secret you need\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\n\n**Run a command with a Tier 2 entry (deploy, publish, infrastructure change):**\n```\n1. vault_entries_list() → find entry ID\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\nNote: Tier 2 entries require the user to enable access from the wundervault.com dashboard before use.\n\n**Write a secret to a config file:**\n```\n1. vault_entries_list() → find entry ID\n2. vault_entry_inject_env(entry_id: \"abc123\", purpose: \"...\", file_path: \"/app/.env\", env_key: \"MY_KEY\")\n```\n\n**Deploy files to a remote server:**\n```\n1. vault_entries_list() → find SSH key entry ID\n2. vault_rsync(ssh_key_entry_id: \"...\", local_path: \"./dist/\", remote_user: \"opc\", remote_host: \"prod.example.com\", remote_path: \"/var/www/html\")\n```\n\n\n## Multi-Agent Setup\n\nWundervault is designed for multi-agent environments. Each agent gets its own scoped identity and token — they are fully isolated from each other at the daemon level.\n\n- Each agent authenticates with its own token file (`~/.wundervault/agents/{AgentName}.token`)\n- Agents can only access entries they have been explicitly granted\n- The vault owner controls which agents exist and what they can reach from the wundervault.com dashboard\n- Agents cannot see each other's tokens, identities, or access scopes\n- Audit logs are per-agent, so you can trace exactly which agent accessed which secret and when\n\nThis makes Wundervault suitable for setups where multiple specialized agents (a coding agent, a deploy agent, a partner agent, etc.) share infrastructure but must not share credentials.\n\n## Security Notes\n\n- Secrets are end-to-end encrypted; plaintext is never returned to the agent\n- The onboarding script verifies its own ed25519 signature on startup and exits if the check fails. Pipe mode (`curl ... | python3`) is hard-blocked — the script detects it and refuses to run. Pinned version, SHA-256 checksum, and public key are at [wundervault.com/install](https://wundervault.com/install).\n- Agents never hold credentials directly — only a scoped token is stored locally. The local daemon manages the actual credentials and exposes them only through its controlled interface, enforcing tier checks and audit logging on every request. Compromise of an agent token does not grant direct access to vault credentials.\n- `vault_exec` and `vault_rsync` are the correct tools for using secrets — not `vault_entry_get`\n- Tier 2 entries are configured by the vault owner; agents cannot escalate a Tier 1 entry\n- Tier 2 access is enabled server-side by the user via the wundervault.com dashboard\n- The `inject_as` override lets you specify which env var name receives the secret if the vault entry has no exec_config set\n\n## More Info\n\n- npm: `@wundervault/mcp-server`\n- Vault UI: [wundervault.com](https://wundervault.com)\n\nFile v1.6.2:_meta.json\n\n{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.6.2\",\n \"publishedAt\": 1778960064950\n}\n\nFile v1.6.2:INSTALL.md\n\n# Installing Wundervault Vault\n\n## Prerequisites\n\n- A Wundervault account — request early access via the [contact form](https://wundervault.com/contact)\n- An agent configured in your Wundervault dashboard (Settings → Agents)\n- Node.js / npm installed\n\n## Step 1 — Install the MCP server\n\n```bash\nnpm install -g @wundervault/mcp-server\n```\n\nOr install locally in your OpenClaw workspace:\n\n```bash\ncd ~/.openclaw/workspace\nnpm install @wundervault/mcp-server\n```\n\n## Step 2 — Run the onboarding script\n\nIn your Wundervault dashboard under **Settings → Agents**, create an agent and copy the setup URL (it includes the passphrase in the `#fragment`). Download the script, then run it:\n\n```bash\ncurl -fsSL https://wundervault.com/onboard -o /tmp/wv-onboard.py\npython3 /tmp/wv-onboard.py \"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\"\n```\n\nThe script must be downloaded before running — pipe mode (`curl ... | python3`) is blocked. The script verifies its own ed25519 signature on startup and exits immediately if the check fails.\n\nPinned version, SHA-256 checksum, and the ed25519 public key for independent verification are available at [wundervault.com/install](https://wundervault.com/install).\n\nThe script will:\n- Verify its own signature before doing anything else\n- Decrypt your credentials locally (passphrase never sent to the server)\n- Save them to `~/.wundervault/creds-{agent_name}.json`\n- Auto-configure OpenClaw (`~/.openclaw/openclaw.json`) if present\n- Clear any stale MCP session so the new credentials take effect immediately\n\n## Multiple agents on the same machine\n\nEach agent gets its own named credentials file (`~/.wundervault/creds-Byte.json`, `~/.wundervault/creds-Claude.json`, etc.). The onboarding script handles this automatically for OpenClaw.\n\nFor other clients (Claude Code, Cursor, Windsurf), set this env var in their MCP config to point at the right file:\n\n```json\n{\n \"mcpServers\": {\n \"wundervault\": {\n \"command\": \"wundervault-mcp\",\n \"env\": {\n \"WUNDERVAULT_CREDENTIALS_FILE\": \"/home/youruser/.wundervault/creds-Claude.json\"\n }\n }\n }\n}\n```\n\nCommon global MCP config locations:\n- **Claude Code**: `~/.claude/mcp.json`\n- **Cursor**: `~/.cursor/mcp.json`\n- **Windsurf**: `~/.codeium/windsurf/mcp_config.json`\n\n## Verify\n\nAsk your agent:\n\n> \"List my vault secrets\"\n\nThe agent should call `vault_entries_list` and show available entries.\n\n## Self-Hosting\n\nWundervault is open-source and can be self-hosted. The onboarding script auto-detects the vault URL from the setup link, so no extra configuration is needed.\n\nFile v1.6.2:skill-card.md\n\n## Description:
\nRead passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected - without exposing them in chat.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[snoweman](https://clawhub.ai/user/snoweman)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and operators use this skill to let an agent work with Wundervault-managed secrets for setup checks, authorized command execution, remote sync, and environment-file configuration without returning plaintext secrets in chat.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill gives agents high-impact authority over real credentials and local configuration.
\nMitigation: Install only when you trust Wundervault, grant each agent only the vault entries it needs, and review command, file, and remote-host targets before use.
\nRisk: Environment-file injection can persist credentials on disk outside the chat-safe vault flow.
\nMitigation: Keep .env injection disabled unless necessary, choose target paths deliberately, and set restrictive permissions on generated .env files.
\nRisk: Setup depends on the Wundervault MCP server and onboarding script.
\nMitigation: Verify the npm package and onboarding script checksum or signature before setup.
\n\n\n## Reference(s):
\n- [ClawHub release page](https://clawhub.ai/snoweman/wundervault-vault)
\n- [Wundervault](https://wundervault.com)
\n- [Wundervault install verification](https://wundervault.com/install)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, shell commands, configuration, guidance]
\n**Output Format:** [Markdown guidance with inline command and configuration examples]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [MCP tool calls can execute commands, sync files, or modify environment files when the user has configured and authorized the vault.]
\n\n## Skill Version(s):
\n1.6.2 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.6.0: 3 files, 5686 bytes\n\nFiles: _meta.json (136b), INSTALL.md (2587b), SKILL.md (9929b)\n\nFile v1.6.0:SKILL.md\n\n---\nname: wundervault-vault\ndescription: Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — without exposing them in chat. Requires a Wundervault account — request early access at wundervault.com.\n---\n\n# Wundervault Vault\n\nWundervault is an encrypted, self-hosted secret vault that exposes secrets to agents via MCP tools. Secrets never appear in chat — they are decrypted server-side and injected directly into commands or written to config files. **The plaintext of a secret is never returned to the agent.**\n\n## Check Setup First\n\nAlways call `vault_entries_list` before doing anything vault-related. Use the result to determine where the user is in setup:\n\n| Result | What it means | What to do |\n|--------|--------------|------------|\n| Returns a list of entries | Vault is connected and ready | Proceed |\n| Returns empty list | Connected but no secrets yet | Tell the user to add secrets at wundervault.com |\n| Returns auth/credentials error | MCP server installed but not onboarded | Walk through onboarding (see below) |\n| Tool not available | MCP server not wired to this agent | Walk through setup (see INSTALL.md) |\n\n### First-run onboarding\n\nIf the vault tools are missing or credentials are invalid, tell the user:\n\n> \"Wundervault isn't set up yet. Here's how to get started:\n> 1. Request access via the [contact form](https://wundervault.com/contact)\n> 2. Once approved, set up your account and onboard your agent at wundervault.com\n> 3. Verify the MCP server package using the checksums at [wundervault.com/install](https://wundervault.com/install)\n> 4. Come back and I'll verify the connection\"\n\nDo not attempt to use any vault tools until `vault_entries_list` succeeds.\n\n## Tools\n\n### `vault_entries_list`\nList all vault entries available to this agent. Returns entry IDs and names only — no secret values.\n\n```\nvault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]\n```\n\nUse this first to get the entry ID before calling any other tool.\n\n### `vault_entry_get`\nRetrieve and burn a secret. The secret is decrypted server-side and **never returned to the agent** — you will receive a burn confirmation only.\n\n```\nvault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\"\n```\n\nUse this only to confirm a secret exists or to acknowledge retrieval. To actually use a secret in a command or file, use `vault_exec` or `vault_entry_inject_env` instead.\n\n### `vault_exec`\nExecute a shell command with a vault secret injected as an environment variable — the secret is never exposed in chat or logs.\n\n```\nvault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")\n```\n\n**Two tiers:**\n- **Tier 1** (standard): runs immediately\n- **Tier 2** (restricted): Tier 2 access is controlled server-side — the user enables it from the wundervault.com dashboard\n\nShell escape sequences (`$()`, backticks, `bash -c`, `eval`) are hard-blocked before the secret is decrypted.\n\n**Remote execution via SSH:** Pass `remote_host` to run the command on a remote machine. The secret is injected inside the remote shell via SSH stdin — no `AcceptEnv`/`SendEnv` config required on the remote host. Use `ssh_key_entry_id` to load the SSH key from the vault itself.\n\n```\nvault_exec(\n entry_id: \"abc123\",\n purpose: \"check subscribers on prod\",\n command: \"curl -s -u \\\"admin:$DB_PASSWORD\\\" http://localhost:9000/api/subscribers\",\n inject_as: { env_key: \"DB_PASSWORD\" },\n remote_host: { host: \"192.168.1.50\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n### `vault_entry_inject_env`\nWrite a secret directly into an environment file (`.env`) as an environment variable, without it passing through chat.\n\n**Disabled by default.** To use this tool, enable it in Settings > Agent Capabilities at wundervault.com. You can disable it again at any time.\n\n```\nvault_entry_inject_env(\n entry_id: \"abc123\",\n purpose: \"inject API key into app config\",\n file_path: \"/home/user/app/.env\",\n env_key: \"RESEND_API_KEY\"\n)\n```\n\nNote: `file_path` and `env_key` are the correct parameter names.\n\n**Why you'd enable it:** Writing secrets directly to `.env` files is the standard way to configure apps, containers, and deploy pipelines. Without this tool, you'd need to paste secrets manually — exposing them in your terminal or chat history. `vault_entry_inject_env` lets agents wire up credentials automatically while keeping plaintext out of the conversation entirely.\n\n**Risks to understand before enabling:**\n- An agent can write a secret to any `.env` path it can reach — including paths outside your project directory\n- If an agent is compromised or acting on a malicious prompt, it could inject credentials into unexpected locations\n- Written secrets are no longer burn-on-read — they persist on disk in the target file\n- File permissions on the `.env` are your responsibility; the tool writes the value but does not set restrictive permissions automatically\n\n### `vault_rsync`\nSync a local directory to a remote host via rsync over SSH, with the SSH key fetched from the vault. The key is written to a temp file for the transfer duration and deleted immediately after.\n\n```\nvault_rsync(\n ssh_key_entry_id: \"ssh-key-entry-id\",\n purpose: \"deploy static files to prod\",\n local_path: \"/home/user/app/dist/\",\n remote_user: \"opc\",\n remote_host: \"prod.example.com\",\n remote_path: \"/var/www/html\"\n)\n```\n\n### `vault_http_post`\nMake an HTTPS request with vault secrets injected directly into headers — the agent never sees the secret values, only the HTTP response.\n\nEach credential is fetched from the vault, interpolated into the format string using `{secret}`, and added as an HTTP header. Plaintext credentials are zeroed after use and never included in the response.\n\n**HTTPS is enforced** — `http://` URLs are rejected before any network activity.\n\n```\nvault_http_post(\n url: \"https://api.example.com/endpoint\",\n body: { key: \"value\" },\n credentials: [\n { entry_id: \"abc123\", header: \"Authorization\", format: \"Bearer {secret}\" },\n { entry_id: \"def456\", header: \"X-Api-Hmac\", format: \"{secret}\" }\n ],\n purpose: \"post data to example API\"\n)\n→ ✅ vault_http_post 200\n {\"ok\": true}\n```\n\nUse this instead of `vault_entry_get` + manual HTTP — credentials never touch the agent's context.\n\n### `vault_entry_forget`\nDiscard a vault entry reference from context. Does not delete the vault entry.\n\n```\nvault_entry_forget(entry_id: \"abc123\")\n→ ✔️ Reference discarded.\n```\n\n## Common Patterns\n\n**Run a command with a secret (Tier 1):**\n```\n1. vault_entries_list() → find entry ID for the secret you need\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\n\n**Run a command with a Tier 2 entry (deploy, publish, infrastructure change):**\n```\n1. vault_entries_list() → find entry ID\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\nNote: Tier 2 entries require the user to enable access from the wundervault.com dashboard before use.\n\n**Write a secret to a config file:**\n```\n1. vault_entries_list() → find entry ID\n2. vault_entry_inject_env(entry_id: \"abc123\", purpose: \"...\", file_path: \"/app/.env\", env_key: \"MY_KEY\")\n```\n\n**Deploy files to a remote server:**\n```\n1. vault_entries_list() → find SSH key entry ID\n2. vault_rsync(ssh_key_entry_id: \"...\", local_path: \"./dist/\", remote_user: \"opc\", remote_host: \"prod.example.com\", remote_path: \"/var/www/html\")\n```\n\n**Make an authenticated HTTP request without exposing credentials:**\n```\n1. vault_entries_list() → find entry IDs for each credential\n2. vault_http_post(url: \"https://...\", body: {...}, credentials: [{entry_id: \"...\", header: \"Authorization\", format: \"Bearer {secret}\"}], purpose: \"...\")\n```\n\n## Multi-Agent Setup\n\nWundervault is designed for multi-agent environments. Each agent gets its own scoped identity and token — they are fully isolated from each other at the daemon level.\n\n- Each agent authenticates with its own token file (`~/.wundervault/agents/{AgentName}.token`)\n- Agents can only access entries they have been explicitly granted\n- The vault owner controls which agents exist and what they can reach from the wundervault.com dashboard\n- Agents cannot see each other's tokens, identities, or access scopes\n- Audit logs are per-agent, so you can trace exactly which agent accessed which secret and when\n\nThis makes Wundervault suitable for setups where multiple specialized agents (a coding agent, a deploy agent, a partner agent, etc.) share infrastructure but must not share credentials.\n\n## Security Notes\n\n- Secrets are end-to-end encrypted; plaintext is never returned to the agent\n- The onboarding script verifies its own ed25519 signature on startup and exits if the check fails. Pipe mode (`curl ... | python3`) is hard-blocked — the script detects it and refuses to run. Pinned version, SHA-256 checksum, and public key are at [wundervault.com/install](https://wundervault.com/install).\n- Agents never hold credentials directly — only a scoped token is stored locally. The local daemon manages the actual credentials and exposes them only through its controlled interface, enforcing tier checks and audit logging on every request. Compromise of an agent token does not grant direct access to vault credentials.\n- `vault_exec`, `vault_rsync`, and `vault_http_post` are the correct tools for using secrets — not `vault_entry_get`\n- Tier 2 entries are configured by the vault owner; agents cannot escalate a Tier 1 entry\n- Tier 2 access is enabled server-side by the user via the wundervault.com dashboard\n- The `inject_as` override lets you specify which env var name receives the secret if the vault entry has no exec_config set\n\n## More Info\n\n- npm: `@wundervault/mcp-server`\n- Vault UI: [wundervault.com](https://wundervault.com)\n\nFile v1.6.0:_meta.json\n\n{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.6.0\",\n \"publishedAt\": 1778953544834\n}\n\nFile v1.6.0:INSTALL.md\n\n# Installing Wundervault Vault\n\n## Prerequisites\n\n- A Wundervault account — request early access via the [contact form](https://wundervault.com/contact)\n- An agent configured in your Wundervault dashboard (Settings → Agents)\n- Node.js / npm installed\n\n## Step 1 — Install the MCP server\n\n```bash\nnpm install -g @wundervault/mcp-server\n```\n\nOr install locally in your OpenClaw workspace:\n\n```bash\ncd ~/.openclaw/workspace\nnpm install @wundervault/mcp-server\n```\n\n## Step 2 — Run the onboarding script\n\nIn your Wundervault dashboard under **Settings → Agents**, create an agent and copy the setup URL (it includes the passphrase in the `#fragment`). Download the script, then run it:\n\n```bash\ncurl -fsSL https://wundervault.com/onboard -o /tmp/wv-onboard.py\npython3 /tmp/wv-onboard.py \"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\"\n```\n\nThe script must be downloaded before running — pipe mode (`curl ... | python3`) is blocked. The script verifies its own ed25519 signature on startup and exits immediately if the check fails.\n\nPinned version, SHA-256 checksum, and the ed25519 public key for independent verification are available at [wundervault.com/install](https://wundervault.com/install).\n\nThe script will:\n- Verify its own signature before doing anything else\n- Decrypt your credentials locally (passphrase never sent to the server)\n- Save them to `~/.wundervault/creds-{agent_name}.json`\n- Auto-configure OpenClaw (`~/.openclaw/openclaw.json`) if present\n- Clear any stale MCP session so the new credentials take effect immediately\n\n## Multiple agents on the same machine\n\nEach agent gets its own named credentials file (`~/.wundervault/creds-Byte.json`, `~/.wundervault/creds-Claude.json`, etc.). The onboarding script handles this automatically for OpenClaw.\n\nFor other clients (Claude Code, Cursor, Windsurf), set this env var in their MCP config to point at the right file:\n\n```json\n{\n \"mcpServers\": {\n \"wundervault\": {\n \"command\": \"wundervault-mcp\",\n \"env\": {\n \"WUNDERVAULT_CREDENTIALS_FILE\": \"/home/youruser/.wundervault/creds-Claude.json\"\n }\n }\n }\n}\n```\n\nCommon global MCP config locations:\n- **Claude Code**: `~/.claude/mcp.json`\n- **Cursor**: `~/.cursor/mcp.json`\n- **Windsurf**: `~/.codeium/windsurf/mcp_config.json`\n\n## Verify\n\nAsk your agent:\n\n> \"List my vault secrets\"\n\nThe agent should call `vault_entries_list` and show available entries.\n\n## Self-Hosting\n\nWundervault is open-source and can be self-hosted. The onboarding script auto-detects the vault URL from the setup link, so no extra configuration is needed.\n\nArchive v1.5.12: 3 files, 5256 bytes\n\nFiles: _meta.json (137b), INSTALL.md (2587b), SKILL.md (8707b)\n\nFile v1.5.12:SKILL.md\n\n---\nname: wundervault-vault\ndescription: Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — without exposing them in chat. Requires a Wundervault account — request early access at wundervault.com.\n---\n\n# Wundervault Vault\n\nWundervault is an encrypted, self-hosted secret vault that exposes secrets to agents via MCP tools. Secrets never appear in chat — they are decrypted server-side and injected directly into commands or written to config files. **The plaintext of a secret is never returned to the agent.**\n\n## Check Setup First\n\nAlways call `vault_entries_list` before doing anything vault-related. Use the result to determine where the user is in setup:\n\n| Result | What it means | What to do |\n|--------|--------------|------------|\n| Returns a list of entries | Vault is connected and ready | Proceed |\n| Returns empty list | Connected but no secrets yet | Tell the user to add secrets at wundervault.com |\n| Returns auth/credentials error | MCP server installed but not onboarded | Walk through onboarding (see below) |\n| Tool not available | MCP server not wired to this agent | Walk through setup (see INSTALL.md) |\n\n### First-run onboarding\n\nIf the vault tools are missing or credentials are invalid, tell the user:\n\n> \"Wundervault isn't set up yet. Here's how to get started:\n> 1. Request access via the [contact form](https://wundervault.com/contact)\n> 2. Once approved, set up your account and onboard your agent at wundervault.com\n> 3. Verify the MCP server package using the checksums at [wundervault.com/install](https://wundervault.com/install)\n> 4. Come back and I'll verify the connection\"\n\nDo not attempt to use any vault tools until `vault_entries_list` succeeds.\n\n## Tools\n\n### `vault_entries_list`\nList all vault entries available to this agent. Returns entry IDs and names only — no secret values.\n\n```\nvault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]\n```\n\nUse this first to get the entry ID before calling any other tool.\n\n### `vault_entry_get`\nRetrieve and burn a secret. The secret is decrypted server-side and **never returned to the agent** — you will receive a burn confirmation only.\n\n```\nvault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\"\n```\n\nUse this only to confirm a secret exists or to acknowledge retrieval. To actually use a secret in a command or file, use `vault_exec` or `vault_entry_inject_env` instead.\n\n### `vault_exec`\nExecute a shell command with a vault secret injected as an environment variable — the secret is never exposed in chat or logs.\n\n```\nvault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")\n```\n\n**Two tiers:**\n- **Tier 1** (standard): runs immediately\n- **Tier 2** (restricted): Tier 2 access is controlled server-side — the user enables it from the wundervault.com dashboard\n\nShell escape sequences (`$()`, backticks, `bash -c`, `eval`) are hard-blocked before the secret is decrypted.\n\n**Remote execution via SSH:** Pass `remote_host` to run the command on a remote machine. The secret is injected inside the remote shell via SSH stdin — no `AcceptEnv`/`SendEnv` config required on the remote host. Use `ssh_key_entry_id` to load the SSH key from the vault itself.\n\n```\nvault_exec(\n entry_id: \"abc123\",\n purpose: \"check subscribers on prod\",\n command: \"curl -s -u \\\"admin:$DB_PASSWORD\\\" http://localhost:9000/api/subscribers\",\n inject_as: { env_key: \"DB_PASSWORD\" },\n remote_host: { host: \"192.168.1.50\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n### `vault_entry_inject_env`\nWrite a secret directly into an environment file (`.env`) as an environment variable, without it passing through chat.\n\n**Disabled by default.** To use this tool, enable it in Settings > Agent Capabilities at wundervault.com. You can disable it again at any time.\n\n```\nvault_entry_inject_env(\n entry_id: \"abc123\",\n purpose: \"inject API key into app config\",\n file_path: \"/home/user/app/.env\",\n env_key: \"RESEND_API_KEY\"\n)\n```\n\nNote: `file_path` and `env_key` are the correct parameter names.\n\n**Why you'd enable it:** Writing secrets directly to `.env` files is the standard way to configure apps, containers, and deploy pipelines. Without this tool, you'd need to paste secrets manually — exposing them in your terminal or chat history. `vault_entry_inject_env` lets agents wire up credentials automatically while keeping plaintext out of the conversation entirely.\n\n**Risks to understand before enabling:**\n- An agent can write a secret to any `.env` path it can reach — including paths outside your project directory\n- If an agent is compromised or acting on a malicious prompt, it could inject credentials into unexpected locations\n- Written secrets are no longer burn-on-read — they persist on disk in the target file\n- File permissions on the `.env` are your responsibility; the tool writes the value but does not set restrictive permissions automatically\n\n### `vault_rsync`\nSync a local directory to a remote host via rsync over SSH, with the SSH key fetched from the vault. The key is written to a temp file for the transfer duration and deleted immediately after.\n\n```\nvault_rsync(\n ssh_key_entry_id: \"ssh-key-entry-id\",\n purpose: \"deploy static files to prod\",\n local_path: \"/home/user/app/dist/\",\n remote_user: \"opc\",\n remote_host: \"prod.example.com\",\n remote_path: \"/var/www/html\"\n)\n```\n\n### `vault_entry_forget`\nDiscard a vault entry reference from context. Does not delete the vault entry.\n\n```\nvault_entry_forget(entry_id: \"abc123\")\n→ ✔️ Reference discarded.\n```\n\n## Common Patterns\n\n**Run a command with a secret (Tier 1):**\n```\n1. vault_entries_list() → find entry ID for the secret you need\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\n\n**Run a command with a Tier 2 entry (deploy, publish, infrastructure change):**\n```\n1. vault_entries_list() → find entry ID\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\nNote: Tier 2 entries require the user to enable access from the wundervault.com dashboard before use.\n\n**Write a secret to a config file:**\n```\n1. vault_entries_list() → find entry ID\n2. vault_entry_inject_env(entry_id: \"abc123\", purpose: \"...\", file_path: \"/app/.env\", env_key: \"MY_KEY\")\n```\n\n**Deploy files to a remote server:**\n```\n1. vault_entries_list() → find SSH key entry ID\n2. vault_rsync(ssh_key_entry_id: \"...\", local_path: \"./dist/\", remote_user: \"opc\", remote_host: \"prod.example.com\", remote_path: \"/var/www/html\")\n```\n\n## Multi-Agent Setup\n\nWundervault is designed for multi-agent environments. Each agent gets its own scoped identity and token — they are fully isolated from each other at the daemon level.\n\n- Each agent authenticates with its own token file (`~/.wundervault/agents/{AgentName}.token`)\n- Agents can only access entries they have been explicitly granted\n- The vault owner controls which agents exist and what they can reach from the wundervault.com dashboard\n- Agents cannot see each other's tokens, identities, or access scopes\n- Audit logs are per-agent, so you can trace exactly which agent accessed which secret and when\n\nThis makes Wundervault suitable for setups where multiple specialized agents (a coding agent, a deploy agent, a partner agent, etc.) share infrastructure but must not share credentials.\n\n## Security Notes\n\n- Secrets are end-to-end encrypted; plaintext is never returned to the agent\n- The onboarding script verifies its own ed25519 signature on startup and exits if the check fails. Pipe mode (`curl ... | python3`) is hard-blocked — the script detects it and refuses to run. Pinned version, SHA-256 checksum, and public key are at [wundervault.com/install](https://wundervault.com/install).\n- Agents never hold credentials directly — only a scoped token is stored locally. The local daemon manages the actual credentials and exposes them only through its controlled interface, enforcing tier checks and audit logging on every request. Compromise of an agent token does not grant direct access to vault credentials.\n- `vault_exec` and `vault_rsync` are the correct tools for using secrets — not `vault_entry_get`\n- Tier 2 entries are configured by the vault owner; agents cannot escalate a Tier 1 entry\n- Tier 2 access is enabled server-side by the user via the wundervault.com dashboard\n- The `inject_as` override lets you specify which env var name receives the secret if the vault entry has no exec_config set\n\n## More Info\n\n- npm: `@wundervault/mcp-server`\n- Vault UI: [wundervault.com](https://wundervault.com)\n\nFile v1.5.12:_meta.json\n\n{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.5.12\",\n \"publishedAt\": 1778780500936\n}\n\nFile v1.5.12:INSTALL.md\n\n# Installing Wundervault Vault\n\n## Prerequisites\n\n- A Wundervault account — request early access via the [contact form](https://wundervault.com/contact)\n- An agent configured in your Wundervault dashboard (Settings → Agents)\n- Node.js / npm installed\n\n## Step 1 — Install the MCP server\n\n```bash\nnpm install -g @wundervault/mcp-server\n```\n\nOr install locally in your OpenClaw workspace:\n\n```bash\ncd ~/.openclaw/workspace\nnpm install @wundervault/mcp-server\n```\n\n## Step 2 — Run the onboarding script\n\nIn your Wundervault dashboard under **Settings → Agents**, create an agent and copy the setup URL (it includes the passphrase in the `#fragment`). Download the script, then run it:\n\n```bash\ncurl -fsSL https://wundervault.com/onboard -o /tmp/wv-onboard.py\npython3 /tmp/wv-onboard.py \"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\"\n```\n\nThe script must be downloaded before running — pipe mode (`curl ... | python3`) is blocked. The script verifies its own ed25519 signature on startup and exits immediately if the check fails.\n\nPinned version, SHA-256 checksum, and the ed25519 public key for independent verification are available at [wundervault.com/install](https://wundervault.com/install).\n\nThe script will:\n- Verify its own signature before doing anything else\n- Decrypt your credentials locally (passphrase never sent to the server)\n- Save them to `~/.wundervault/creds-{agent_name}.json`\n- Auto-configure OpenClaw (`~/.openclaw/openclaw.json`) if present\n- Clear any stale MCP session so the new credentials take effect immediately\n\n## Multiple agents on the same machine\n\nEach agent gets its own named credentials file (`~/.wundervault/creds-Byte.json`, `~/.wundervault/creds-Claude.json`, etc.). The onboarding script handles this automatically for OpenClaw.\n\nFor other clients (Claude Code, Cursor, Windsurf), set this env var in their MCP config to point at the right file:\n\n```json\n{\n \"mcpServers\": {\n \"wundervault\": {\n \"command\": \"wundervault-mcp\",\n \"env\": {\n \"WUNDERVAULT_CREDENTIALS_FILE\": \"/home/youruser/.wundervault/creds-Claude.json\"\n }\n }\n }\n}\n```\n\nCommon global MCP config locations:\n- **Claude Code**: `~/.claude/mcp.json`\n- **Cursor**: `~/.cursor/mcp.json`\n- **Windsurf**: `~/.codeium/windsurf/mcp_config.json`\n\n## Verify\n\nAsk your agent:\n\n> \"List my vault secrets\"\n\nThe agent should call `vault_entries_list` and show available entries.\n\n## Self-Hosting\n\nWundervault is open-source and can be self-hosted. The onboarding script auto-detects the vault URL from the setup link, so no extra configuration is needed.\n\nArchive v1.5.11: 3 files, 4933 bytes\n\nFiles: _meta.json (137b), INSTALL.md (2587b), SKILL.md (7840b)\n\nFile v1.5.11:SKILL.md\n\n---\nname: wundervault-vault\ndescription: Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — without exposing them in chat. Requires a Wundervault account — request early access at wundervault.com.\n---\n\n# Wundervault Vault\n\nWundervault is an encrypted, self-hosted secret vault that exposes secrets to agents via MCP tools. Secrets never appear in chat — they are decrypted server-side and injected directly into commands or written to config files. **The plaintext of a secret is never returned to the agent.**\n\n## Check Setup First\n\nBefore doing anything vault-related, verify the vault tools are available:\n\n- Call `vault_entries_list` — if it returns entries, vault is connected and ready\n- If the tool is missing from your tool set, tell the user the MCP server is not wired to your agent context (see INSTALL.md)\n\n## Tools\n\n### `vault_entries_list`\nList all vault entries available to this agent. Returns entry IDs and names only — no secret values.\n\n```\nvault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]\n```\n\nUse this first to get the entry ID before calling any other tool.\n\n### `vault_entry_get`\nRetrieve and burn a secret. The secret is decrypted server-side and **never returned to the agent** — you will receive a burn confirmation only.\n\n```\nvault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\"\n```\n\nUse this only to confirm a secret exists or to acknowledge retrieval. To actually use a secret in a command or file, use `vault_exec` or `vault_entry_inject_env` instead.\n\n### `vault_exec`\nExecute a shell command with a vault secret injected as an environment variable — the secret is never exposed in chat or logs.\n\n```\nvault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")\n```\n\n**Two tiers:**\n- **Tier 1** (standard): runs immediately\n- **Tier 2** (restricted): Tier 2 access is controlled server-side — the user enables it from the wundervault.com dashboard\n\nShell escape sequences (`$()`, backticks, `bash -c`, `eval`) are hard-blocked before the secret is decrypted.\n\n**Remote execution via SSH:** Pass `remote_host` to run the command on a remote machine. The secret is injected inside the remote shell via SSH stdin — no `AcceptEnv`/`SendEnv` config required on the remote host. Use `ssh_key_entry_id` to load the SSH key from the vault itself.\n\n```\nvault_exec(\n entry_id: \"abc123\",\n purpose: \"check subscribers on prod\",\n command: \"curl -s -u \\\"admin:$DB_PASSWORD\\\" http://localhost:9000/api/subscribers\",\n inject_as: { env_key: \"DB_PASSWORD\" },\n remote_host: { host: \"192.168.1.50\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n### `vault_entry_inject_env`\nWrite a secret directly into an environment file (`.env`) as an environment variable, without it passing through chat.\n\n**Disabled by default.** To use this tool, enable it in Settings > Agent Capabilities at wundervault.com. You can disable it again at any time.\n\n```\nvault_entry_inject_env(\n entry_id: \"abc123\",\n purpose: \"inject API key into app config\",\n file_path: \"/home/user/app/.env\",\n env_key: \"RESEND_API_KEY\"\n)\n```\n\nNote: `file_path` and `env_key` are the correct parameter names.\n\n**Why you'd enable it:** Writing secrets directly to `.env` files is the standard way to configure apps, containers, and deploy pipelines. Without this tool, you'd need to paste secrets manually — exposing them in your terminal or chat history. `vault_entry_inject_env` lets agents wire up credentials automatically while keeping plaintext out of the conversation entirely.\n\n**Risks to understand before enabling:**\n- An agent can write a secret to any `.env` path it can reach — including paths outside your project directory\n- If an agent is compromised or acting on a malicious prompt, it could inject credentials into unexpected locations\n- Written secrets are no longer burn-on-read — they persist on disk in the target file\n- File permissions on the `.env` are your responsibility; the tool writes the value but does not set restrictive permissions automatically\n\n### `vault_rsync`\nSync a local directory to a remote host via rsync over SSH, with the SSH key fetched from the vault. The key is written to a temp file for the transfer duration and deleted immediately after.\n\n```\nvault_rsync(\n ssh_key_entry_id: \"ssh-key-entry-id\",\n purpose: \"deploy static files to prod\",\n local_path: \"/home/user/app/dist/\",\n remote_user: \"opc\",\n remote_host: \"prod.example.com\",\n remote_path: \"/var/www/html\"\n)\n```\n\n### `vault_entry_forget`\nDiscard a vault entry reference from context. Does not delete the vault entry.\n\n```\nvault_entry_forget(entry_id: \"abc123\")\n→ ✔️ Reference discarded.\n```\n\n## Common Patterns\n\n**Run a command with a secret (Tier 1):**\n```\n1. vault_entries_list() → find entry ID for the secret you need\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\n\n**Run a command with a Tier 2 entry (deploy, publish, infrastructure change):**\n```\n1. vault_entries_list() → find entry ID\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\nNote: Tier 2 entries require the user to enable access from the wundervault.com dashboard before use.\n\n**Write a secret to a config file:**\n```\n1. vault_entries_list() → find entry ID\n2. vault_entry_inject_env(entry_id: \"abc123\", purpose: \"...\", file_path: \"/app/.env\", env_key: \"MY_KEY\")\n```\n\n**Deploy files to a remote server:**\n```\n1. vault_entries_list() → find SSH key entry ID\n2. vault_rsync(ssh_key_entry_id: \"...\", local_path: \"./dist/\", remote_user: \"opc\", remote_host: \"prod.example.com\", remote_path: \"/var/www/html\")\n```\n\n## Multi-Agent Setup\n\nWundervault is designed for multi-agent environments. Each agent gets its own scoped identity and token — they are fully isolated from each other at the daemon level.\n\n- Each agent authenticates with its own token file (`~/.wundervault/agents/{AgentName}.token`)\n- Agents can only access entries they have been explicitly granted\n- The vault owner controls which agents exist and what they can reach from the wundervault.com dashboard\n- Agents cannot see each other's tokens, identities, or access scopes\n- Audit logs are per-agent, so you can trace exactly which agent accessed which secret and when\n\nThis makes Wundervault suitable for setups where multiple specialized agents (a coding agent, a deploy agent, a partner agent, etc.) share infrastructure but must not share credentials.\n\n## Security Notes\n\n- Secrets are end-to-end encrypted; plaintext is never returned to the agent\n- The onboarding script verifies its own ed25519 signature on startup and exits if the check fails. Pipe mode (`curl ... | python3`) is hard-blocked — the script detects it and refuses to run. Pinned version, SHA-256 checksum, and public key are at [wundervault.com/install](https://wundervault.com/install).\n- Agents never hold credentials directly — only a scoped token is stored locally. The local daemon manages the actual credentials and exposes them only through its controlled interface, enforcing tier checks and audit logging on every request. Compromise of an agent token does not grant direct access to vault credentials.\n- `vault_exec` and `vault_rsync` are the correct tools for using secrets — not `vault_entry_get`\n- Tier 2 entries are configured by the vault owner; agents cannot escalate a Tier 1 entry\n- Tier 2 access is enabled server-side by the user via the wundervault.com dashboard\n- The `inject_as` override lets you specify which env var name receives the secret if the vault entry has no exec_config set\n\n## More Info\n\n- npm: `@wundervault/mcp-server`\n- Vault UI: [wundervault.com](https://wundervault.com)\n\nFile v1.5.11:_meta.json\n\n{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.5.11\",\n \"publishedAt\": 1778734824989\n}\n\nFile v1.5.11:INSTALL.md\n\n# Installing Wundervault Vault\n\n## Prerequisites\n\n- A Wundervault account — request early access via the [contact form](https://wundervault.com/contact)\n- An agent configured in your Wundervault dashboard (Settings → Agents)\n- Node.js / npm installed\n\n## Step 1 — Install the MCP server\n\n```bash\nnpm install -g @wundervault/mcp-server\n```\n\nOr install locally in your OpenClaw workspace:\n\n```bash\ncd ~/.openclaw/workspace\nnpm install @wundervault/mcp-server\n```\n\n## Step 2 — Run the onboarding script\n\nIn your Wundervault dashboard under **Settings → Agents**, create an agent and copy the setup URL (it includes the passphrase in the `#fragment`). Download the script, then run it:\n\n```bash\ncurl -fsSL https://wundervault.com/onboard -o /tmp/wv-onboard.py\npython3 /tmp/wv-onboard.py \"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\"\n```\n\nThe script must be downloaded before running — pipe mode (`curl ... | python3`) is blocked. The script verifies its own ed25519 signature on startup and exits immediately if the check fails.\n\nPinned version, SHA-256 checksum, and the ed25519 public key for independent verification are available at [wundervault.com/install](https://wundervault.com/install).\n\nThe script will:\n- Verify its own signature before doing anything else\n- Decrypt your credentials locally (passphrase never sent to the server)\n- Save them to `~/.wundervault/creds-{agent_name}.json`\n- Auto-configure OpenClaw (`~/.openclaw/openclaw.json`) if present\n- Clear any stale MCP session so the new credentials take effect immediately\n\n## Multiple agents on the same machine\n\nEach agent gets its own named credentials file (`~/.wundervault/creds-Byte.json`, `~/.wundervault/creds-Claude.json`, etc.). The onboarding script handles this automatically for OpenClaw.\n\nFor other clients (Claude Code, Cursor, Windsurf), set this env var in their MCP config to point at the right file:\n\n```json\n{\n \"mcpServers\": {\n \"wundervault\": {\n \"command\": \"wundervault-mcp\",\n \"env\": {\n \"WUNDERVAULT_CREDENTIALS_FILE\": \"/home/youruser/.wundervault/creds-Claude.json\"\n }\n }\n }\n}\n```\n\nCommon global MCP config locations:\n- **Claude Code**: `~/.claude/mcp.json`\n- **Cursor**: `~/.cursor/mcp.json`\n- **Windsurf**: `~/.codeium/windsurf/mcp_config.json`\n\n## Verify\n\nAsk your agent:\n\n> \"List my vault secrets\"\n\nThe agent should call `vault_entries_list` and show available entries.\n\n## Self-Hosting\n\nWundervault is open-source and can be self-hosted. The onboarding script auto-detects the vault URL from the setup link, so no extra configuration is needed.\n\nArchive v1.5.10: 3 files, 4593 bytes\n\nFiles: _meta.json (137b), INSTALL.md (2170b), SKILL.md (7529b)\n\nFile v1.5.10:SKILL.md\n\n---\nname: wundervault-vault\ndescription: Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — without exposing them in chat. Requires a Wundervault account — request early access at wundervault.com.\n---\n\n# Wundervault Vault\n\nWundervault is an encrypted, self-hosted secret vault that exposes secrets to agents via MCP tools. Secrets never appear in chat — they are decrypted server-side and injected directly into commands or written to config files. **The plaintext of a secret is never returned to the agent.**\n\n## Check Setup First\n\nBefore doing anything vault-related, verify the vault tools are available:\n\n- Call `vault_entries_list` — if it returns entries, vault is connected and ready\n- If the tool is missing from your tool set, tell the user the MCP server is not wired to your agent context (see INSTALL.md)\n\n## Tools\n\n### `vault_entries_list`\nList all vault entries available to this agent. Returns entry IDs and names only — no secret values.\n\n```\nvault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]\n```\n\nUse this first to get the entry ID before calling any other tool.\n\n### `vault_entry_get`\nRetrieve and burn a secret. The secret is decrypted server-side and **never returned to the agent** — you will receive a burn confirmation only.\n\n```\nvault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\"\n```\n\nUse this only to confirm a secret exists or to acknowledge retrieval. To actually use a secret in a command or file, use `vault_exec` or `vault_entry_inject_env` instead.\n\n### `vault_exec`\nExecute a shell command with a vault secret injected as an environment variable — the secret is never exposed in chat or logs.\n\n```\nvault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")\n```\n\n**Two tiers:**\n- **Tier 1** (standard): runs immediately\n- **Tier 2** (restricted): Tier 2 access is controlled server-side — the user enables it from the wundervault.com dashboard\n\nShell escape sequences (`$()`, backticks, `bash -c`, `eval`) are hard-blocked before the secret is decrypted.\n\n**Remote execution via SSH:** Pass `remote_host` to run the command on a remote machine. The secret is injected inside the remote shell via SSH stdin — no `AcceptEnv`/`SendEnv` config required on the remote host. Use `ssh_key_entry_id` to load the SSH key from the vault itself.\n\n```\nvault_exec(\n entry_id: \"abc123\",\n purpose: \"check subscribers on prod\",\n command: \"curl -s -u \\\"admin:$DB_PASSWORD\\\" http://localhost:9000/api/subscribers\",\n inject_as: { env_key: \"DB_PASSWORD\" },\n remote_host: { host: \"192.168.1.50\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n### `vault_entry_inject_env`\nWrite a secret directly into an environment file (`.env`) as an environment variable, without it passing through chat.\n\n**Disabled by default.** To use this tool, enable it in Settings > Agent Capabilities at wundervault.com. You can disable it again at any time.\n\n```\nvault_entry_inject_env(\n entry_id: \"abc123\",\n purpose: \"inject API key into app config\",\n file_path: \"/home/user/app/.env\",\n env_key: \"RESEND_API_KEY\"\n)\n```\n\nNote: `file_path` and `env_key` are the correct parameter names.\n\n**Why you'd enable it:** Writing secrets directly to `.env` files is the standard way to configure apps, containers, and deploy pipelines. Without this tool, you'd need to paste secrets manually — exposing them in your terminal or chat history. `vault_entry_inject_env` lets agents wire up credentials automatically while keeping plaintext out of the conversation entirely.\n\n**Risks to understand before enabling:**\n- An agent can write a secret to any `.env` path it can reach — including paths outside your project directory\n- If an agent is compromised or acting on a malicious prompt, it could inject credentials into unexpected locations\n- Written secrets are no longer burn-on-read — they persist on disk in the target file\n- File permissions on the `.env` are your responsibility; the tool writes the value but does not set restrictive permissions automatically\n\n### `vault_rsync`\nSync a local directory to a remote host via rsync over SSH, with the SSH key fetched from the vault. The key is written to a temp file for the transfer duration and deleted immediately after.\n\n```\nvault_rsync(\n ssh_key_entry_id: \"ssh-key-entry-id\",\n purpose: \"deploy static files to prod\",\n local_path: \"/home/user/app/dist/\",\n remote_user: \"opc\",\n remote_host: \"prod.example.com\",\n remote_path: \"/var/www/html\"\n)\n```\n\n### `vault_entry_forget`\nDiscard a vault entry reference from context. Does not delete the vault entry.\n\n```\nvault_entry_forget(entry_id: \"abc123\")\n→ ✔️ Reference discarded.\n```\n\n## Common Patterns\n\n**Run a command with a secret (Tier 1):**\n```\n1. vault_entries_list() → find entry ID for the secret you need\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\n\n**Run a command with a Tier 2 entry (deploy, publish, infrastructure change):**\n```\n1. vault_entries_list() → find entry ID\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\nNote: Tier 2 entries require the user to enable access from the wundervault.com dashboard before use.\n\n**Write a secret to a config file:**\n```\n1. vault_entries_list() → find entry ID\n2. vault_entry_inject_env(entry_id: \"abc123\", purpose: \"...\", file_path: \"/app/.env\", env_key: \"MY_KEY\")\n```\n\n**Deploy files to a remote server:**\n```\n1. vault_entries_list() → find SSH key entry ID\n2. vault_rsync(ssh_key_entry_id: \"...\", local_path: \"./dist/\", remote_user: \"opc\", remote_host: \"prod.example.com\", remote_path: \"/var/www/html\")\n```\n\n## Multi-Agent Setup\n\nWundervault is designed for multi-agent environments. Each agent gets its own scoped identity and token — they are fully isolated from each other at the daemon level.\n\n- Each agent authenticates with its own token file (`~/.wundervault/agents/{AgentName}.token`)\n- Agents can only access entries they have been explicitly granted\n- The vault owner controls which agents exist and what they can reach from the wundervault.com dashboard\n- Agents cannot see each other's tokens, identities, or access scopes\n- Audit logs are per-agent, so you can trace exactly which agent accessed which secret and when\n\nThis makes Wundervault suitable for setups where multiple specialized agents (a coding agent, a deploy agent, a partner agent, etc.) share infrastructure but must not share credentials.\n\n## Security Notes\n\n- Secrets are end-to-end encrypted; plaintext is never returned to the agent\n- Agents never hold credentials directly — only a scoped token is stored locally. The local daemon manages the actual credentials and exposes them only through its controlled interface, enforcing tier checks and audit logging on every request. Compromise of an agent token does not grant direct access to vault credentials.\n- `vault_exec` and `vault_rsync` are the correct tools for using secrets — not `vault_entry_get`\n- Tier 2 entries are configured by the vault owner; agents cannot escalate a Tier 1 entry\n- Tier 2 access is enabled server-side by the user via the wundervault.com dashboard\n- The `inject_as` override lets you specify which env var name receives the secret if the vault entry has no exec_config set\n\n## More Info\n\n- npm: `@wundervault/mcp-server`\n- Vault UI: [wundervault.com](https://wundervault.com)\n\nFile v1.5.10:_meta.json\n\n{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.5.10\",\n \"publishedAt\": 1778733239128\n}\n\nFile v1.5.10:INSTALL.md\n\n# Installing Wundervault Vault\n\n## Prerequisites\n\n- A Wundervault account — registration is invite-only. Request access via the [contact form](https://wundervault.com/contact)\n- An agent configured in your Wundervault dashboard (Settings → Agents)\n- Node.js / npm installed\n\n## Step 1 — Install the MCP server\n\n```bash\nnpm install -g @wundervault/mcp-server\n```\n\nOr install locally in your OpenClaw workspace:\n\n```bash\ncd ~/.openclaw/workspace\nnpm install @wundervault/mcp-server\n```\n\n## Step 2 — Run the onboarding script\n\nIn your Wundervault dashboard under **Settings → Agents**, create an agent and copy the setup URL (it includes the passphrase in the `#fragment`). Then run:\n\n```bash\ncurl -fsSL https://wundervault.com/onboard -o /tmp/wv-onboard.py\npython3 /tmp/wv-onboard.py \"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\"\n```\n\nThe script will:\n- Decrypt your credentials locally (passphrase never sent to the server)\n- Save them to `~/.wundervault/creds-{agent_name}.json`\n- Auto-configure OpenClaw (`~/.openclaw/openclaw.json`) if present\n- Clear any stale MCP session so the new credentials take effect immediately\n\n## Multiple agents on the same machine\n\nEach agent gets its own named credentials file (`~/.wundervault/creds-Byte.json`, `~/.wundervault/creds-Claude.json`, etc.). The onboarding script handles this automatically for OpenClaw.\n\nFor other clients (Claude Code, Cursor, Windsurf), set this env var in their MCP config to point at the right file:\n\n```json\n{\n \"mcpServers\": {\n \"wundervault\": {\n \"command\": \"wundervault-mcp\",\n \"env\": {\n \"WUNDERVAULT_CREDENTIALS_FILE\": \"/home/youruser/.wundervault/creds-Claude.json\"\n }\n }\n }\n}\n```\n\nCommon global MCP config locations:\n- **Claude Code**: `~/.claude/mcp.json`\n- **Cursor**: `~/.cursor/mcp.json`\n- **Windsurf**: `~/.codeium/windsurf/mcp_config.json`\n\n## Verify\n\nAsk your agent:\n\n> \"List my vault secrets\"\n\nThe agent should call `vault_entries_list` and show available entries.\n\n## Self-Hosting\n\nWundervault is open-source and can be self-hosted. The onboarding script auto-detects the vault URL from the setup link, so no extra configuration is needed.\n\nArchive v1.5.9: 5 files, 5236 bytes\n\nFiles: INSTALL.md (2709b), meta.json (136b), publish.py (1823b), SKILL.md (5660b), _meta.json (136b)\n\nFile v1.5.9:SKILL.md\n\n---\nname: wundervault-vault\ndescription: Read passwords, API keys, and credentials from a Wundervault encrypted secret vault, and run vault-authorized shell commands with secrets injected — without exposing them in chat. Requires a Wundervault account at wundervault.com — registration is invite-only. Request access at wundervault.com/contact.\n---\n\n# Wundervault Vault\n\n> **Account required:** Wundervault is a hosted service at [wundervault.com](https://wundervault.com) — this is **not** a self-hosted tool. Registration is currently invite-only. [Request an invite code](https://wundervault.com/contact) before installing.\n\nWundervault is an encrypted secret vault that exposes secrets to agents via MCP tools. Secrets never appear in chat — they are decrypted server-side and injected directly into commands or written to config files. **The plaintext of a secret is never returned to the agent.**\n\n## Check Setup First\n\nBefore doing anything vault-related, verify the vault tools are available:\n\n- Call `vault_entries_list` — if it returns entries, vault is connected and ready\n- If the tool is missing from your tool set, tell the user the MCP server is not wired to your agent context (see INSTALL.md)\n\n## Tools\n\n### `vault_entries_list`\nList all vault entries available to this agent. Returns entry IDs and names only — no secret values.\n\n```\nvault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]\n```\n\nUse this first to get the entry ID before calling any other tool.\n\n### `vault_entry_get`\nRetrieve and burn a secret. The secret is decrypted server-side and **never returned to the agent** — you will receive a burn confirmation only.\n\n```\nvault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\"\n```\n\nUse this only to confirm a secret exists or to acknowledge retrieval. To actually use a secret in a command or file, use `vault_exec` or `vault_entry_inject_env` instead.\n\n### `vault_exec`\nExecute a shell command with a vault secret injected as an environment variable — the secret is never exposed in chat or logs.\n\n```\nvault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")\n```\n\n**Two tiers:**\n- **Tier 1** (standard): runs immediately\n- **Tier 2** (restricted): Tier 2 access is controlled server-side — the user enables it from the wundervault.com dashboard\n\nShell escape sequences (`$()`, backticks, `bash -c`, `eval`) are hard-blocked before the secret is decrypted.\n\n**Remote execution via SSH:** Pass `remote_host` to run the command on a remote machine. The secret is injected inside the remote shell via SSH stdin — no `AcceptEnv`/`SendEnv` config required on the remote host. Use `ssh_key_entry_id` to load the SSH key from the vault itself.\n\n```\nvault_exec(\n entry_id: \"abc123\",\n purpose: \"check subscribers on prod\",\n command: \"curl -s -u \\\"admin:$DB_PASSWORD\\\" http://localhost:9000/api/subscribers\",\n inject_as: { env_key: \"DB_PASSWORD\" },\n remote_host: { host: \"192.168.1.50\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n### `vault_entry_inject_env`\nWrite a secret directly into an environment file (`.env`) as an environment variable, without it passing through chat.\n\n```\nvault_entry_inject_env(\n entry_id: \"abc123\",\n purpose: \"inject API key into app config\",\n file_path: \"/home/user/app/.env\",\n env_key: \"RESEND_API_KEY\"\n)\n```\n\nNote: `file_path` and `env_key` are the correct parameter names.\n\n### `vault_rsync`\nSync a local directory to a remote host via rsync over SSH, with the SSH key fetched from the vault. The key is written to a temp file for the transfer duration and deleted immediately after.\n\n```\nvault_rsync(\n ssh_key_entry_id: \"ssh-key-entry-id\",\n purpose: \"deploy static files to prod\",\n local_path: \"/home/user/app/dist/\",\n remote_user: \"opc\",\n remote_host: \"prod.example.com\",\n remote_path: \"/var/www/html\"\n)\n```\n\n### `vault_entry_forget`\nDiscard a vault entry reference from context. Does not delete the vault entry.\n\n```\nvault_entry_forget(entry_id: \"abc123\")\n→ ✔️ Reference discarded.\n```\n\n## Common Patterns\n\n**Run a command with a secret (Tier 1):**\n```\n1. vault_entries_list() → find entry ID for the secret you need\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\n\n**Run a command with a Tier 2 entry (deploy, publish, infrastructure change):**\n```\n1. vault_entries_list() → find entry ID\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\nNote: Tier 2 entries require the user to enable access from the wundervault.com dashboard before use.\n\n**Write a secret to a config file:**\n```\n1. vault_entries_list() → find entry ID\n2. vault_entry_inject_env(entry_id: \"abc123\", purpose: \"...\", file_path: \"/app/.env\", env_key: \"MY_KEY\")\n```\n\n**Deploy files to a remote server:**\n```\n1. vault_entries_list() → find SSH key entry ID\n2. vault_rsync(ssh_key_entry_id: \"...\", local_path: \"./dist/\", remote_user: \"opc\", remote_host: \"prod.example.com\", remote_path: \"/var/www/html\")\n```\n\n## Security Notes\n\n- Secrets are end-to-end encrypted; plaintext is never returned to the agent\n- `vault_exec` and `vault_rsync` are the correct tools for using secrets — not `vault_entry_get`\n- Tier 2 entries are configured by the vault owner; agents cannot escalate a Tier 1 entry\n- Tier 2 access is enabled server-side by the user via the wundervault.com dashboard\n- The `inject_as` override lets you specify which env var name receives the secret if the vault entry has no exec_config set\n\n## More Info\n\n- npm: `@wundervault/mcp-server`\n- Vault UI: [wundervault.com](https://wundervault.com)\n\nFile v1.5.9:_meta.json\n\n{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.5.9\",\n \"publishedAt\": 1778701712076\n}\n\nFile v1.5.9:INSTALL.md\n\n# Installing Wundervault Vault\n\n## Prerequisites\n\n- A Wundervault account — registration is invite-only. Request access via the [contact form](https://wundervault.com/contact)\n- An agent configured in your Wundervault dashboard (Settings → Agents)\n- Node.js / npm installed\n\n## Step 1 — Install the MCP server\n\n```bash\nnpm install -g @wundervault/mcp-server\n```\n\nOr install locally in your OpenClaw workspace:\n\n```bash\ncd ~/.openclaw/workspace\nnpm install @wundervault/mcp-server\n```\n\n## Step 2 — Run the onboarding script\n\nIn your Wundervault dashboard under **Settings → Agents**, create an agent and copy the setup URL (it includes the passphrase in the `#fragment`). Then run:\n\n```bash\n# Recommended: fetch the pinned versioned script, verify its SHA-256 checksum, then run with\n# the setup URL in an env var (keeps the passphrase out of shell history and process listings)\ncurl -fsSL https://wundervault.com/onboard/v1.5.9 -o /tmp/wv-onboard.py\nEXPECTED=$(curl -fsSL https://wundervault.com/onboard/v1.5.9.sha256)\nACTUAL=$(sha256sum /tmp/wv-onboard.py | awk '{print $1}')\n[ \"$EXPECTED\" = \"$ACTUAL\" ] || { echo \"Checksum mismatch — aborting\"; exit 1; }\nWV_SETUP_URL=\"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\" python3 /tmp/wv-onboard.py\n```\n\nOr use the unversioned URL — the script self-verifies its ed25519 signature on run and supports the same env var approach:\n\n```bash\ncurl -fsSL https://wundervault.com/onboard -o /tmp/wv-onboard.py\nWV_SETUP_URL=\"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\" python3 /tmp/wv-onboard.py\n```\n\nThe script will:\n- Decrypt your credentials locally (passphrase never sent to the server)\n- Save them to `~/.wundervault/creds-{agent_name}.json`\n- Auto-configure OpenClaw (`~/.openclaw/openclaw.json`) if present\n- Clear any stale MCP session so the new credentials take effect immediately\n\n## Multiple agents on the same machine\n\nEach agent gets its own named credentials file (`~/.wundervault/creds-Byte.json`, `~/.wundervault/creds-Claude.json`, etc.). The onboarding script handles this automatically for OpenClaw.\n\nFor other clients (Claude Code, Cursor, Windsurf), set this env var in their MCP config to point at the right file:\n\n```json\n{\n \"mcpServers\": {\n \"wundervault\": {\n \"command\": \"wundervault-mcp\",\n \"env\": {\n \"WUNDERVAULT_CREDENTIALS_FILE\": \"/home/youruser/.wundervault/creds-Claude.json\"\n }\n }\n }\n}\n```\n\nCommon global MCP config locations:\n- **Claude Code**: `~/.claude/mcp.json`\n- **Cursor**: `~/.cursor/mcp.json`\n- **Windsurf**: `~/.codeium/windsurf/mcp_config.json`\n\n## Verify\n\nAsk your agent:\n\n> \"List my vault secrets\"\n\nThe agent should call `vault_entries_list` and show available entries.\n\nFile v1.5.9:meta.json\n\n{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.4.0\",\n \"publishedAt\": 1778189178705\n}\n\nArchive v1.5.8: 3 files, 3689 bytes\n\nFiles: _meta.json (136b), INSTALL.md (2170b), SKILL.md (5400b)\n\nFile v1.5.8:SKILL.md\n\n---\nname: wundervault-vault\ndescription: Read passwords, API keys, and credentials from a Wundervault encrypted secret vault, and run vault-authorized shell commands with secrets injected — without exposing them in chat. Self-hosted alternative to 1Password or Bitwarden for agents. Requires the @wundervault/mcp-server npm package.\n---\n\n# Wundervault Vault\n\nWundervault is an encrypted, self-hosted secret vault that exposes secrets to agents via MCP tools. Secrets never appear in chat — they are decrypted server-side and injected directly into commands or written to config files. **The plaintext of a secret is never returned to the agent.**\n\n## Check Setup First\n\nBefore doing anything vault-related, verify the vault tools are available:\n\n- Call `vault_entries_list` — if it returns entries, vault is connected and ready\n- If the tool is missing from your tool set, tell the user the MCP server is not wired to your agent context (see INSTALL.md)\n\n## Tools\n\n### `vault_entries_list`\nList all vault entries available to this agent. Returns entry IDs and names only — no secret values.\n\n```\nvault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]\n```\n\nUse this first to get the entry ID before calling any other tool.\n\n### `vault_entry_get`\nRetrieve and burn a secret. The secret is decrypted server-side and **never returned to the agent** — you will receive a burn confirmation only.\n\n```\nvault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\"\n```\n\nUse this only to confirm a secret exists or to acknowledge retrieval. To actually use a secret in a command or file, use `vault_exec` or `vault_entry_inject_env` instead.\n\n### `vault_exec`\nExecute a shell command with a vault secret injected as an environment variable — the secret is never exposed in chat or logs.\n\n```\nvault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")\n```\n\n**Two tiers:**\n- **Tier 1** (standard): runs immediately\n- **Tier 2** (restricted): Tier 2 access is controlled server-side — the user enables it from the wundervault.com dashboard\n\nShell escape sequences (`$()`, backticks, `bash -c`, `eval`) are hard-blocked before the secret is decrypted.\n\n**Remote execution via SSH:** Pass `remote_host` to run the command on a remote machine. The secret is injected inside the remote shell via SSH stdin — no `AcceptEnv`/`SendEnv` config required on the remote host. Use `ssh_key_entry_id` to load the SSH key from the vault itself.\n\n```\nvault_exec(\n entry_id: \"abc123\",\n purpose: \"check subscribers on prod\",\n command: \"curl -s -u \\\"admin:$DB_PASSWORD\\\" http://localhost:9000/api/subscribers\",\n inject_as: { env_key: \"DB_PASSWORD\" },\n remote_host: { host: \"192.168.1.50\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)\n```\n\n### `vault_entry_inject_env`\nWrite a secret directly into an environment file (`.env`) as an environment variable, without it passing through chat.\n\n```\nvault_entry_inject_env(\n entry_id: \"abc123\",\n purpose: \"inject API key into app config\",\n file_path: \"/home/user/app/.env\",\n env_key: \"RESEND_API_KEY\"\n)\n```\n\nNote: `file_path` and `env_key` are the correct parameter names.\n\n### `vault_rsync`\nSync a local directory to a remote host via rsync over SSH, with the SSH key fetched from the vault. The key is written to a temp file for the transfer duration and deleted immediately after.\n\n```\nvault_rsync(\n ssh_key_entry_id: \"ssh-key-entry-id\",\n purpose: \"deploy static files to prod\",\n local_path: \"/home/user/app/dist/\",\n remote_user: \"opc\",\n remote_host: \"prod.example.com\",\n remote_path: \"/var/www/html\"\n)\n```\n\n### `vault_entry_forget`\nDiscard a vault entry reference from context. Does not delete the vault entry.\n\n```\nvault_entry_forget(entry_id: \"abc123\")\n→ ✔️ Reference discarded.\n```\n\n## Common Patterns\n\n**Run a command with a secret (Tier 1):**\n```\n1. vault_entries_list() → find entry ID for the secret you need\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\n\n**Run a command with a Tier 2 entry (deploy, publish, infrastructure change):**\n```\n1. vault_entries_list() → find entry ID\n2. vault_exec(entry_id: \"abc123\", purpose: \"...\", command: \"...\")\n```\nNote: Tier 2 entries require the user to enable access from the wundervault.com dashboard before use.\n\n**Write a secret to a config file:**\n```\n1. vault_entries_list() → find entry ID\n2. vault_entry_inject_env(entry_id: \"abc123\", purpose: \"...\", file_path: \"/app/.env\", env_key: \"MY_KEY\")\n```\n\n**Deploy files to a remote server:**\n```\n1. vault_entries_list() → find SSH key entry ID\n2. vault_rsync(ssh_key_entry_id: \"...\", local_path: \"./dist/\", remote_user: \"opc\", remote_host: \"prod.example.com\", remote_path: \"/var/www/html\")\n```\n\n## Security Notes\n\n- Secrets are end-to-end encrypted; plaintext is never returned to the agent\n- `vault_exec` and `vault_rsync` are the correct tools for using secrets — not `vault_entry_get`\n- Tier 2 entries are configured by the vault owner; agents cannot escalate a Tier 1 entry\n- Tier 2 access is enabled server-side by the user via the wundervault.com dashboard\n- The `inject_as` override lets you specify which env var name receives the secret if the vault entry has no exec_config set\n\n## More Info\n\n- npm: `@wundervault/mcp-server`\n- Vault UI: [wundervault.com](https://wundervault.com)\n\nFile v1.5.8:_meta.json\n\n{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.5.8\",\n \"publishedAt\": 1778642545990\n}\n\nFile v1.5.8:INSTALL.md\n\n# Installing Wundervault Vault\n\n## Prerequisites\n\n- A Wundervault account — registration is invite-only. Request access via the [contact form](https://wundervault.com/contact)\n- An agent configured in your Wundervault dashboard (Settings → Agents)\n- Node.js / npm installed\n\n## Step 1 — Install the MCP server\n\n```bash\nnpm install -g @wundervault/mcp-server\n```\n\nOr install locally in your OpenClaw workspace:\n\n```bash\ncd ~/.openclaw/workspace\nnpm install @wundervault/mcp-server\n```\n\n## Step 2 — Run the onboarding script\n\nIn your Wundervault dashboard under **Settings → Agents**, create an agent and copy the setup URL (it includes the passphrase in the `#fragment`). Then run:\n\n```bash\ncurl -fsSL https://wundervault.com/onboard -o /tmp/wv-onboard.py\npython3 /tmp/wv-onboard.py \"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\"\n```\n\nThe script will:\n- Decrypt your credentials locally (passphrase never sent to the server)\n- Save them to `~/.wundervault/creds-{agent_name}.json`\n- Auto-configure OpenClaw (`~/.openclaw/openclaw.json`) if present\n- Clear any stale MCP session so the new credentials take effect immediately\n\n## Multiple agents on the same machine\n\nEach agent gets its own named credentials file (`~/.wundervault/creds-Byte.json`, `~/.wundervault/creds-Claude.json`, etc.). The onboarding script handles this automatically for OpenClaw.\n\nFor other clients (Claude Code, Cursor, Windsurf), set this env var in their MCP config to point at the right file:\n\n```json\n{\n \"mcpServers\": {\n \"wundervault\": {\n \"command\": \"wundervault-mcp\",\n \"env\": {\n \"WUNDERVAULT_CREDENTIALS_FILE\": \"/home/youruser/.wundervault/creds-Claude.json\"\n }\n }\n }\n}\n```\n\nCommon global MCP config locations:\n- **Claude Code**: `~/.claude/mcp.json`\n- **Cursor**: `~/.cursor/mcp.json`\n- **Windsurf**: `~/.codeium/windsurf/mcp_config.json`\n\n## Verify\n\nAsk your agent:\n\n> \"List my vault secrets\"\n\nThe agent should call `vault_entries_list` and show available entries.\n\n## Self-Hosting\n\nWundervault is open-source and can be self-hosted. The onboarding script auto-detects the vault URL from the setup link, so no extra configuration is needed.","readmeExcerpt":"Skill: Wundervault Vault Owner: snoweman Summary: Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — wit... Tags: api-keys:1.0.1, credentials:1.0.1, latest:1.6.9, mcp:1.5.8, passwords:1.0.1, secrets:1.5.8, security:1.5.8, self-hosted:1.0.1, vault:1.5.8 Version history: v1.6.9 | 2026-07-13T19:43:28.069Z | user Tier-2","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"vault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]"},{"language":"text","snippet":"vault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\""},{"language":"text","snippet":"vault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")"},{"language":"text","snippet":"vault_exec(\n entry_id: \"abc123\",\n purpose: \"check subscribers on prod\",\n command: \"curl -s -u \\\"admin:$DB_PASSWORD\\\" http://localhost:9000/api/subscribers\",\n inject_as: { env_key: \"DB_PASSWORD\" },\n remote_host: { host: \"192.168.1.50\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)"},{"language":"text","snippet":"vault_exec(\n purpose: \"restart the service on prod\",\n command: \"sudo systemctl restart wundervault\",\n remote_host: { host: \"prod.example.com\", user: \"opc\", ssh_key_entry_id: \"ssh-key-entry-id\" }\n)"},{"language":"text","snippet":"vault_entry_inject_env(\n entry_id: \"abc123\",\n purpose: \"inject API key into app config\",\n file_path: \"/home/user/app/.env\",\n env_key: \"RESEND_API_KEY\"\n)"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: wundervault-vault\ndescription: Read passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected — without exposing them in chat. Requires a Wundervault account — request early access at wundervault.com.\n---\n\n# Wundervault Vault\n\nWundervault is an encrypted, self-hosted secret vault that exposes secrets to agents via MCP tools. Secrets never appear in chat — they are decrypted server-side and injected directly into commands or written to config files. **The plaintext of a secret is never returned to the agent.**\n\n## Check Setup First\n\nAlways call `vault_entries_list` before doing anything vault-related. Use the result to determine where the user is in setup:\n\n| Result | What it means | What to do |\n|--------|--------------|------------|\n| Returns a list of entries | Vault is connected and ready | Proceed |\n| Returns empty list | Connected but no secrets yet | Tell the user to add secrets at wundervault.com |\n| Returns auth/credentials error | MCP server installed but not onboarded | Walk through onboarding (see below) |\n| Tool not available | MCP server not wired to this agent | Walk through setup (see INSTALL.md) |\n\n### First-run onboarding\n\nIf the vault tools are missing or credentials are invalid, tell the user:\n\n> \"Wundervault isn't set up yet. Here's how to get started:\n> 1. Request access via the [contact form](https://wundervault.com/contact)\n> 2. Once approved, set up your account and onboard your agent at wundervault.com\n> 3. Verify the MCP server package using the checksums at [wundervault.com/install](https://wundervault.com/install)\n> 4. Come back and I'll verify the connection\"\n\nDo not attempt to use any vault tools until `vault_entries_list` succeeds.\n\n## Tools\n\n### `vault_entries_list`\nList all vault entries available to this agent. Returns entry IDs and names only — no secret values.\n\n```\nvault_entries_list()\n→ [{ id: \"abc123\", name: \"ResendApiKey\", tier: \"full\" }, ...]\n```\n\nUse this first to get the entry ID before calling any other tool.\n\n### `vault_entry_get`\nRetrieve and burn a secret. The secret is decrypted server-side and **never returned to the agent** — you will receive a burn confirmation only.\n\n```\nvault_entry_get(entry_id: \"abc123\", purpose: \"confirm secret exists\")\n→ \"✅ Secret retrieved and burned.\"\n```\n\nUse this only to confirm a secret exists or to acknowledge retrieval. To actually use a secret in a command or file, use `vault_exec` or `vault_entry_inject_env` instead.\n\n### `vault_exec`\nExecute a shell command with a vault secret injected as an environment variable — the secret is never exposed in chat or logs.\n\n```\nvault_exec(entry_id: \"abc123\", purpose: \"publish package\", command: \"npm publish --access public\")\n```\n\n**Two tiers:**\n- **Tier 1** (standard): runs immediately\n- **Tier 2** (restricted): the call is denied until the owner approves. The denial carries a request id and the owner is emailed automatically; appro"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn7byy043qx59kc8z8h01510sn85rbw4\",\n \"slug\": \"wundervault-vault\",\n \"version\": \"1.6.9\",\n \"publishedAt\": 1783971808069\n}"},{"path":"INSTALL.md","content":"# Installing Wundervault Vault\n\n## Prerequisites\n\n- A Wundervault account — request early access via the [contact form](https://wundervault.com/contact)\n- An agent configured in your Wundervault dashboard (Settings → Agents)\n- Node.js / npm installed\n\n## Step 1 — Install the MCP server\n\n```bash\nnpm install -g @wundervault/mcp-server\n```\n\nOr install locally in your OpenClaw workspace:\n\n```bash\ncd ~/.openclaw/workspace\nnpm install @wundervault/mcp-server\n```\n\n## Step 2 — Run the onboarding script\n\nIn your Wundervault dashboard under **Settings → Agents**, create an agent and copy the setup URL (it includes the passphrase in the `#fragment`). Download the script, then run it:\n\n```bash\ncurl -fsSL https://wundervault.com/onboard -o /tmp/wv-onboard.py\npython3 /tmp/wv-onboard.py \"https://wundervault.com/setup/agent/TOKEN#PASSPHRASE\"\n```\n\nThe script must be downloaded before running — pipe mode (`curl ... | python3`) is blocked. The script verifies its own ed25519 signature on startup and exits immediately if the check fails.\n\nPinned version, SHA-256 checksum, and the ed25519 public key for independent verification are available at [wundervault.com/install](https://wundervault.com/install).\n\nThe script will:\n- Verify its own signature before doing anything else\n- Decrypt your credentials locally (passphrase never sent to the server)\n- Save them to `~/.wundervault/creds-{agent_name}.json`\n- Auto-configure OpenClaw (`~/.openclaw/openclaw.json`) if present\n- Clear any stale MCP session so the new credentials take effect immediately\n\n## Multiple agents on the same machine\n\nEach agent gets its own named credentials file (`~/.wundervault/creds-Byte.json`, `~/.wundervault/creds-Claude.json`, etc.). The onboarding script handles this automatically for OpenClaw.\n\nFor other clients (Claude Code, Cursor, Windsurf), set this env var in their MCP config to point at the right file:\n\n```json\n{\n \"mcpServers\": {\n \"wundervault\": {\n \"command\": \"wundervault-mcp\",\n \"env\": {\n \"WUNDERVAULT_CREDENTIALS_FILE\": \"/home/youruser/.wundervault/creds-Claude.json\"\n }\n }\n }\n}\n```\n\nCommon global MCP config locations:\n- **Claude Code**: `~/.claude/mcp.json`\n- **Cursor**: `~/.cursor/mcp.json`\n- **Windsurf**: `~/.codeium/windsurf/mcp_config.json`\n\n## Verify\n\nAsk your agent:\n\n> \"List my vault secrets\"\n\nThe agent should call `vault_entries_list` and show available entries.\n\n## Self-Hosting\n\nWundervault is open-source and can be self-hosted. The onboarding script auto-detects the vault URL from the setup link, so no extra configuration is needed."},{"path":"skill-card.md","content":"## Description:\n\nRead passwords, API keys, and credentials from a Wundervault zero-knowledge, multi-agent vault, and run authorized shell commands with secrets injected without exposing secret values in chat.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[snoweman](https://clawhub.ai/user/snoweman)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and agent operators use this skill to connect agents to Wundervault, list scoped vault entries, and run approved commands or configuration updates with secrets injected outside the chat transcript.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Installing or onboarding the MCP server for real secrets can expose high-value credentials if the package or onboarding script is not reviewed first.\n\nMitigation: Verify pinned package versions, checksums, and the onboarding script before installation, and review the skill before granting secrets, SSH keys, deployment authority, wallet keys, or .env write access.\n\nRisk: Secret injection into .env files can persist credentials on disk or write them to unexpected paths.\n\nMitigation: Keep .env injection disabled unless needed, restrict each agent to necessary vault entries and command authority, and review target paths and file permissions before enabling it.\n\nRisk: Commands run with injected secrets can affect deployment, publishing, infrastructure, or wallet-signing workflows.\n\nMitigation: Use scoped vault entries, approval for sensitive entries, purpose strings, and audit review before retrying denied operations.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/snoweman/skills/wundervault-vault)\n- [Wundervault install verification](https://wundervault.com/install)\n- [Wundervault zero-knowledge verification](https://wundervault.com/verify)\n- [Wundervault agent wallets](https://wundervault.com/agent-wallets)\n- [Wundervault](https://wundervault.com)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Shell commands, Configuration]\n\n**Output Format:** [Markdown with inline code blocks and MCP tool-call examples]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Agent-facing output should reference vault entries and actions without returning plaintext secret values.]\n\n## Skill Version(s):\n\n1.6.9 (source: server release metadata and artifact metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":1558,"uniquenessScore":44,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T20:07:34.066Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T20:07:34.066Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T02:03:03.040Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}