Vnsh

vnsh

One workspace all your AI agents can read and write

Website • Get Started • Links • How It Works • API • Self-Hosting

---

Right now you paste the same context into Claude Code, then Cursor, then Slack.

vnsh gives that context one address instead. Drop it once and get a link; every agent and every person you hand it to opens the same living document, and can change it. Encrypted in your browser before upload, so vnsh never sees it, and deleted 24 hours after the last edit.

kubectl logs pod/app | vn

https://vnsh.dev/w/k2p9xf...#w=... edit link — read and write

https://vnsh.dev/w/k2p9xf...#r=... view-only — read, never write

Why this and not a pastebin

A pastebin gives you a snapshot. A workspace has a stable address and a version, so the next agent writes back to the same place instead of starting a new one. Two properties make that safe to share:

• The server cannot read it. Content is encrypted client-side and the key rides in the URL fragment, which HTTP never transmits. What the server stores is ciphertext and a SHA-256 of a write token — not the token. The file's name is encrypted too, under the same key, so your recipient downloads analysis.py while vnsh holds a string it cannot decode. That is checkable from outside: forge a token and you get a 403.
• Two agents cannot silently clobber each other. Writes are conditional on the version you read. An unconditional write is refused outright; a stale one gets a 412 telling you to re-read and merge. Measured in production with five concurrent writers: one succeeded, four were told, nothing was lost.

Get started

For an agent — the point of the thing

Paste this into Claude Code, Cursor, OpenHands, Cline, Windsurf, Zed — anything that speaks MCP:

Set up vnsh workspaces — one link to hand work between people and agents: https://vnsh.dev/llms.txt

It reads the protocol, installs the MCP server, and writes a standing rule into its own instruction file so it keeps using workspaces afterwards. By hand instead:

claude mcp add vnsh -- npx -y vnsh-mcp@1.9.0

The server exposes vnsh_artifact_create, vnsh_artifact_list, vnsh_artifact_read, vnsh_artifact_update, vnsh_workspace_create, vnsh_workspace_read, vnsh_workspace_update, vnsh_workspace_history, vnsh_workspace_restore, vnsh_workspace_renew and vnsh_workspace_open, plus vnsh_share, vnsh_share_file and vnsh_read for one-shot content.

From the terminal

npx vnsh                      # or: npm i -g vnsh

or: curl -sL vnsh.dev/i | sh (one-shot links only)

vn ./report.html # create a workspace from a file git diff | vn # or from stdin vn read " " # read one back — workspace, public, or legacy blob vn write " " ./new # replace the contents; refuses to clobber vn history " " # list the latest 20 retained versions vn restore " " 3 # restore v3 as a new latest version vn init . # teach agents in this project to use vnsh

vn init adds an idempotent managed section to the project's agent instruction file. It works across agent vendors and records only an anonymous "project initialized" dimension when that CLI later creates a workspace, so the experiment can be measured without collecting a project name or path.

--public publishes it unencrypted (see below). --blob explicitly makes a one-shot link. --ttl works for workspaces too, up to 168 hours; subsequent writes preserve that lifetime, and vn renew can extend it without an edit.

The dependency-free shell function from curl -sL vnsh.dev/i | sh handles one-shot links only. Workspaces need HKDF-SHA256 and AES-256-GCM, and the openssl that ships with macOS is LibreSSL, which has neither — it hands /w/ links to npx vnsh when Node is available and says so plainly when it is not.

From a browser

https://vnsh.dev — drop a file or paste, and get both links back. Nothing is uploaded before it is encrypted.

From CI

upload-to-vnsh uploads build output or failing test logs and prints a link in the job summary.

From Chrome

The extension previews vnsh links inline on GitHub, Slack and Discord, and bundles a screenshot, console errors and the page URL into one link with ⌘D.

The three kinds of link

The view-only tier is not a setting the server enforces — it is arithmetic. The content key is HKDF(secret, "vnsh/enc/v2"), a one-way derivation, so its holder can decrypt every version while being unable to recover the secret and therefore unable to derive a write token.

Public workspaces exist because a person opening a link has a browser doing the decryption for them, and an agent's fetch does not. A public workspace is stored as written and served as an ordinary document, so anything that speaks HTTP can read it with no key and no setup. The trade is stated where you choose it: vnsh can read a public workspace. It is never the default and never inferred, its visibility is fixed at creation, and changing it still requires the write token.

They are served from `vnshcontent.dev`, a separate registrable domain, and that is not cosmetic. A public document is written by a stranger and rendered as a top-level page, while reputation systems — Safe Browsing, mail gateways, corporate proxies — list a domain rather than a path. One abusive page on vnsh.dev would take the API, the site and every installed CLI, MCP server and extension down with it. A subdomain would not help; the unit is the registrable domain. Sandboxing is a separate matter and already handled: a public document is served with a sandbox CSP directive, so it loads into an opaque origin with no cookies, no storage, no network and no access to any other page. /w/ links stay on vnsh.dev because the key in the fragment is a real gate — the server has never seen their plaintext and neither can a crawler.

Don't assemble a public URL yourself. Creating one returns the exact link in the response's url field, which is also what keeps a self-hosted single-domain instance working.

How it works

you ──encrypt──▶ [ vnsh: ciphertext, no key ] ──decrypt──▶ agent / person

│ deleted 24h after the last write

Key schedule

S = random(32)                        root secret, lives only in the fragment

K = HKDF-SHA256(S, "vnsh/enc/v2") content key — AES-256-GCM W = HKDF-SHA256(S, "vnsh/write/v2") write token, sent as 64 hex chars H = SHA-256(W) the only derived value the server stores

Workspaces use AES-256-GCM, not the AES-256-CBC of one-shot blobs, because mutable content needs integrity: without an authentication tag, anyone able to rewrite storage — the host included — could flip ciphertext bits undetectably, which hollows out the whole guarantee. Nonces are random per write and prepended, never derived from a version number.

The viewer renders HTML and markdown in a frame with sandbox="allow-scripts" and deliberately no allow-same-origin, so content runs in an opaque origin and cannot read the key out of location.hash; an injected default-src 'none' removes its network access.

The whole protocol is specified in /llms.txt, creation included, so you can implement it in any language with a crypto library and run no vnsh code at all. Someone did, in about 200 lines.

API

Writes answer 428 without If-Match, 412 on a stale version, and 403 on a bad write token. Full reference in docs/api.md.

Security model

Accounts and permanent artifacts

Anonymous sharing remains account-free and temporary. Sign in at https://account.vnsh.dev with a magic link to keep newly created workspaces and /artifact/ pages until you delete them. Browser creates use the signed-in session automatically. For the CLI, run vn login and approve the device in your browser. MCP and CI can use an account token in VNSH_TOKEN; content is still encrypted locally for capability-link workspaces, and the account database stores only their ownership metadata, not keys or plaintext. During the free preview, each account can keep 100 documents and 1 GB total, including retained versions. Keep the returned link: its fragment is the only copy of the decryption/editing secret, so the account can manage retention and deletion but cannot recover a lost key.

Phase 1 account Artifacts add a separate collaboration mode: authenticated humans and Agent tokens can discover and version private Artifact content without carrying a fragment key. That convenience has a different security boundary—vnsh can technically read account Artifact content. It is never silently substituted for an anonymous encrypted workspace, and only a human may approve or publish by default.

vn login

vn artifact create report.md --title "Release report" --type report vn artifact list --query release --status draft vn artifact read vn artifact update report.md --base-version 1 --change-summary "Verified production"

Add --json to any Artifact command when another program or Agent will consume the result.

What holds. vnsh cannot read encrypted content, cannot write to it, and cannot recover a write token from anything it stores. Rendered content runs with no same-origin access and no network,