Overview

Vault holds content written directly to Hyperspell: uploaded documents, saved notes, and work summaries captured by agents. These become searchable memories. Vault supports .

Authentication

Vault needs no external provider connection. Reading or writing it still requires Hyperspell authentication and follows your permissions.

Agent work summaries

The Claude activity plugin and Codex activity plugin save structured work summaries here. A capture asks for a title, two to five summary sentences, decisions, next steps, and links. That sentence count is a writing target, not a fixed storage quota. The plugins normally reuse one memory per repository and branch across sessions when the saved entry ID is available. Later captures update that memory. Another machine without the saved ID can create a separate entry. On a server with work history enabled, each changed capture also keeps a private, immutable checkpoint of that summary. Repeating the same content adds no new checkpoint. For an existing entry, history starts with its available current content when it is next revised; older overwritten versions cannot be recovered. Capture does not upload the full conversation, every tool result, or file contents. Summarization can omit details. Checkpoints preserve what was captured, not what the model left out. Documents or transcripts deliberately uploaded through other Vault operations are separate from automatic capture. With a personal credential, suggest keeps a captured entry private until you approve sharing; personal creates no sharing request. Ask your agent to review pending entries and share or keep them private using the sharing tools or CLI. Once shared, later revisions remain shared. Keeping a pending request private does not revoke existing access.

Example: one fix, two sessions

Imagine you are fixing duplicate checkout submissions on a branch called fix-checkout. You use the same plugin installation on the same machine for both sessions, signed in with a personal credential and capture set to suggest. The examples below show illustrative memory content; the agent writes the actual wording from your work.

First session: investigate and save

You reproduce the bug, inspect logs, and try two approaches. Working turns update the plugin’s local note; they do not each upload a new memory. Before stopping, you request a capture with /hyperspell-activity now in Claude or $hyperspell-activity now in Codex. After a successful capture, your Vault memory might contain:

Title: Identified duplicate checkout submissions

Summary: Reproduced duplicate orders when checkout was submitted twice before
the first request completed. Traced the issue to requests being processed
without an idempotency check.

Decisions:
- Enforce idempotency on the server because disabling the button alone
  cannot protect against retries.

Next steps:
- Add the idempotency check and a regression test.

Links:
- The checkout bug's issue URL.

The conversation may have contained many messages and pages of logs. This short entry is what capture sends to Hyperspell. With suggest, it is private and appears in your pending sharing requests.

Second session: continue and update

You start another session, select the local handoff for this work, implement the check, and run the regression test. After the next successful capture, the same Vault memory might read:

Title: Fixed duplicate checkout submissions

Summary: Fixed duplicate orders by adding a server-side idempotency check.
A regression test passed for repeated submissions with the same key.

Decisions:
- Kept the safeguard on the server so it covers both double-clicks and retries.

Next steps:
- Review and deploy the fix.

Links:
- The checkout bug's issue URL.
- The fix's pull request URL.

Searching now finds the updated entry. With work history enabled, you can also ask your agent to read the checkpoint of the first capture. It preserves the earlier investigation summary and its links. Full logs, failed experiments, and exact messages omitted from that summary are not recoverable from the checkpoint. Ask your agent: “Show me the pending checkout entry so I can read it.” Then, when you are ready: “Share that entry with the team.” The agent can apply that decision through the sharing tools without opening the dashboard. Your teammate can ask the brain “Why did we use server-side idempotency?” or “What remains before the checkout fix ships?” and retrieve the saved explanation. The entry does not give them your original conversation or enough information to answer “What exactly did every failed test print?” If you later capture “Deployed and verified the fix” into this entry, your teammate can see that update too. Sharing is attached to the memory, so later captures do not ask for approval again. The private checkpoints remain yours. Sharing the current entry does not let your teammate browse earlier captures.

After this action	What is in Vault	Who can read it
First successful capture	Investigation summary	You
Second successful capture	Updated fix summary in the same memory	You
Approve sharing	That same fix summary	You and your company, subject to content rules
Capture the deployment outcome	Updated summary in the same shared memory	You and your company, subject to content rules

This example assumes the saved entry ID remains available. A different machine, a different plugin, or an unavailable saved entry can produce a separate memory. Local handoff notes and remote Vault entries are separate: resuming local work does not restore a full conversation transcript. Ask your agent: “Find the earlier capture of this work where we chose the retry strategy, and show me its decisions and links.” Hosted MCP provides list_activity_history to list or search captures of a known Vault entry, and get_activity_checkpoint to read one in bounded sections. These are summaries recorded by the agent, not independent proof of its claims. Follow the source links to verify a decision; a newer capture alone does not invalidate every older fact. Source links keep their own access permissions. To share a particular capture, ask the agent to preview it with request_activity_checkpoint_sharing, then confirm creating a separate Vault copy. The copy goes through the normal sharing review and content rules. Approve its request with the sharing tools when ready: list requests with kind="all" and match the copy’s exact source/resource ID, since the default activity filter excludes checkpoint copies. This shares only the copy; future captures do not update it, and your private history stays private. An edited copy is never silently replaced by a repeated request. These operations require a personal credential and an updated server. Company read keys cannot read private history. As with other personal Vault data, a trusted backend holding an app-admin key can explicitly act on behalf of a user; private history is not isolated from that app-admin authority. The CLI offers the same operations; installing an activity plugin alone does not update the server or CLI. Checkpoints are fetched on demand, not loaded in full at the start of every session. Filtered entries and their history cannot be read. Updating a filtered entry discards its hidden archive in the same transaction; a clean replacement starts fresh. This prevents old filtered content from becoming readable again. Deleting the original work entry deletes its private checkpoints. Account or app erasure also removes them. A separately created copy has its own lifecycle and is not deleted with the original entry. There is currently no automatic expiry for checkpoints; do not treat them as temporary storage.

Search Options

Following options are available for the options parameter of vault:

string

The collection to search through. If not provided, all collections will be searched.

Resources

The Vault integration returns Document resources:

Show Document Schema

string

required

The memory’s unique identifier within Vault

string

required

The source of the document: vault.

string

The title of the memory

text

A summary of the document that can be fed directly into LLMs. Query results may summarize only the sections returned as highlights.

elements[]

A structured representation of the memory’s content when reading the document. Search results use highlights for the relevant sections.

highlight[]

A list of passages from the memory relevant to a search query.

​Overview

​Authentication

​Agent work summaries

​Example: one fix, two sessions

​First session: investigate and save

​Second session: continue and update

​Share it with a teammate

​Read or share an earlier capture

​Search Options

​Resources

Overview

Authentication

Agent work summaries

Example: one fix, two sessions

First session: investigate and save

Second session: continue and update

Share it with a teammate

Read or share an earlier capture

Search Options

Resources