vault-fetch
Fetch a URL, extract its text content, and persist it as a semantic memory.
Mindset
Any URL the user pastes that represents reference material — documentation, an issue, an RFC, a blog post — should be fetched proactively without waiting to be asked. If the URL will be useful in more than the current message, persist it.
When to use
- User shares a documentation link to consult during the project
- A GitHub issue or PR contains important context
- External reference material needs to be available across sessions
How to use
vault-cli fetch "<url>" [--project <id>]
The content is automatically:
- Captured with
tier: semanticandforceCapture: true - Truncated to 4000 characters
- Tagged with the source URL
No --tier flag is needed or accepted — tier is set automatically.
Error handling
If the fetch fails (non-2xx response, timeout, or auth-gated page), fall back to capturing the URL and title manually:
vault-cli capture --text "Reference: <title> — <url>" --tier semantic --tags reference,<topic>
Examples
vault-cli fetch "https://bun.sh/docs/api/sqlite"
vault-cli fetch "https://github.com/org/repo/issues/42" --project my-app
vault-cli fetch "https://datatracker.ietf.org/doc/html/rfc9457" --project api
Never
- Never add
--tier— tier is set automatically tosemantic; passing it will cause an error - Never fetch auth-gated URLs (e.g. private GitHub repos, internal wikis behind SSO) — they return 401/403 and capture an error page instead of useful content; use the manual capture fallback instead
- Never fetch
file://orlocalhostURLs — these are local paths unavailable to the fetch command - Never wait to be asked when the user pastes a reference URL — fetch it proactively