vnsh
Compartilhamento de arquivos criptografados efêmeros para IA. Criptografia AES-256 no lado do cliente, autovaporização em 24h.
Documentação
vnsh
Um workspace para todos os seus agentes de IA lerem e escreverem
Site • Comece agora • Links • Como funciona • API • Self-Hosting
Agora você cola o mesmo contexto no Claude Code, depois no Cursor, depois no Slack.
O vnsh dá a esse contexto um único endereço. Cole uma vez e receba um link; cada agente e cada pessoa para quem você o enviar abre o mesmo documento vivo, e pode alterá-lo. Criptografado no seu navegador antes do upload, então o vnsh nunca o vê, e excluído 24 horas após a última edição.
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
Por que isso e não um pastebin
Um pastebin dá a você um instantâneo. Um workspace tem um endereço estável e uma versão, então o próximo agente escreve de volta no mesmo lugar em vez de começar um novo. Duas propriedades tornam isso seguro para compartilhar:
- O servidor não pode lê-lo. O conteúdo é criptografado no lado do cliente e a chave viaja no fragmento da URL, que o HTTP nunca transmite. O que o servidor armazena é texto cifrado e um SHA-256 de um token de escrita — não o token. Isso é verificável de fora: forje um token e você recebe um 403.
- Dois agentes não podem se sobrescrever silenciosamente. As escritas são condicionais à versão que você leu. Uma escrita incondicional é recusada de imediato; uma desatualizada recebe um 412 informando para você reler e mesclar. Medido em produção com cinco escritores concorrentes: um teve sucesso, quatro foram avisados, nada foi perdido.
Comece agora
Para um agente — o ponto central da coisa
Cole isso no Claude Code, Cursor, OpenHands, Cline, Windsurf, Zed — qualquer coisa que fale MCP:
Set up vnsh workspaces — one link to hand work between people and agents: https://vnsh.dev/llms.txt
Ele lê o protocolo, instala o servidor MCP e escreve uma regra permanente no próprio arquivo de instruções para continuar usando workspaces depois. À mão, em vez disso:
claude mcp add vnsh -- npx -y vnsh-mcp@1.8.2
O servidor expõe 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 e vnsh_workspace_open, além de
vnsh_share, vnsh_share_file e vnsh_read para conteúdo de uso único.
Pelo 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 "<any vnsh url>" # read one back — workspace, public, or legacy blob
vn write "<edit url>" ./new # replace the contents; refuses to clobber
vn history "<workspace url>" # list the latest 20 retained versions
vn restore "<edit url>" 3 # restore v3 as a new latest version
vn init . # teach agents in this project to use vnsh
vn init adiciona uma seção gerenciada idempotente ao arquivo de instruções do agente do projeto.
Funciona entre fornecedores de agentes e registra apenas uma dimensão anônima
"projeto inicializado" quando esse CLI depois cria um workspace, para que o
experimento possa ser medido sem coletar um nome de projeto ou caminho.
--public publica sem criptografia (veja abaixo). --blob cria explicitamente um
link de uso único. --ttl também funciona para workspaces, até 168 horas; escritas
subsequentes preservam essa vida útil, e vn renew pode estendê-la sem uma edição.
A função de shell sem dependências de curl -sL vnsh.dev/i | sh lida apenas com
links de uso único. Workspaces precisam de HKDF-SHA256 e AES-256-GCM, e o
openssl que acompanha o macOS é o LibreSSL, que não tem nenhum dos dois — ele entrega /w/
links para npx vnsh quando o Node está disponível e diz isso claramente quando não está.
Pelo navegador
https://vnsh.dev — solte um arquivo ou cole, e receba os dois links de volta. Nada é enviado antes de ser criptografado.
Pelo CI
upload-to-vnsh envia a saída de build
ou logs de testes com falha e imprime um link no resumo do job.
Pelo Chrome
A extensão pré-visualiza links do vnsh inline no GitHub, Slack e Discord, e agrupa uma captura de tela, erros de console e a URL da página em um único link com ⌘D.
Os três tipos de link
| Link | Carrega | Quem pode ler | Quem pode escrever |
|---|---|---|---|
vnsh.dev/w/{id}#w=<secret> | o segredo raiz | qualquer um com o link | qualquer um com o link |
vnsh.dev/w/{id}#r=<key> | a chave de conteúdo | qualquer um com o link | ninguém |
vnshcontent.dev/p/{id} | nada | qualquer pessoa | apenas o link #w= do autor |
O nível somente leitura não é uma configuração que o servidor impõe — é aritmética. A
chave de conteúdo é HKDF(secret, "vnsh/enc/v2"), uma derivação de mão única, então seu detentor
pode descriptografar cada versão sem conseguir recuperar o segredo e, portanto,
sem conseguir derivar um token de escrita.
Workspaces públicos existem porque uma pessoa abrindo um link tem um navegador fazendo
a descriptografia por ela, e o fetch de um agente não tem. Um workspace público é
armazenado como escrito e servido como um documento comum, então qualquer coisa que fale
HTTP pode lê-lo sem chave e sem configuração. A troca é declarada onde você a escolhe:
o vnsh pode ler um workspace público. Nunca é o padrão e nunca é
inferido, sua visibilidade é fixada na criação, e alterá-la ainda exige o
token de escrita.
Eles são servidos de vnshcontent.dev, um domínio registrável separado, e
isso não é cosmético. Um documento público é escrito por um estranho e renderizado como
uma página de nível superior, enquanto sistemas de reputação — Safe Browsing, gateways
de e-mail, proxies corporativos — listam um domínio em vez de um caminho. Uma página abusiva em
vnsh.dev derrubaria a API, o site e cada CLI, servidor MCP e extensão instalados
junto. Um subdomínio não ajudaria; a unidade é o domínio registrável.
O sandboxing é uma questão separada e já tratada: um documento público
é servido com uma diretiva CSP sandbox, então ele carrega em uma origem opaca com
sem cookies, sem armazenamento, sem rede e sem acesso a qualquer outra página. Links /w/
permanecem em vnsh.dev porque a chave no fragmento é uma barreira real — o servidor
nunca viu o texto simples deles e um rastreador também não pode.
Não monte uma URL pública você mesmo. Criar uma retorna o link exato no
campo url da resposta, que também é o que mantém uma instância self-hosted de domínio único
funcionando.
Como funciona
you ──encrypt──▶ [ vnsh: ciphertext, no key ] ──decrypt──▶ agent / person
│
deleted 24h after the last write
Agenda de chaves
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 usam AES-256-GCM, não o AES-256-CBC de blobs de uso único, porque conteúdo mutável precisa de integridade: sem uma tag de autenticação, qualquer um capaz de reescrever o armazenamento — o host incluído — poderia alterar bits do texto cifrado de forma indetectável, o que esvazia toda a garantia. Nonces são aleatórios por escrita e prefixados, nunca derivados de um número de versão.
O visualizador renderiza HTML e markdown em um frame com sandbox="allow-scripts"
e deliberadamente sem allow-same-origin, então o conteúdo roda em uma origem opaca e
não pode ler a chave de location.hash; um default-src 'none' injetado
remove seu acesso à rede.
Todo o protocolo é especificado em /llms.txt,
criação incluída, então você pode implementá-lo em qualquer linguagem com uma biblioteca de criptografia
e não rodar nenhum código do vnsh. Alguém fez, em cerca de 200 linhas.
API
| Endpoint | Propósito |
|---|---|
POST /api/workspace | Criar. Exige X-Vnsh-Write-Hash; X-Vnsh-Public: 1 para publicar. Retorna url quando público. |
GET /api/workspace/:id | Ler texto cifrado. ETag é a versão. |
PUT /api/workspace/:id | Substituir. Exige X-Vnsh-Write e If-Match. |
GET /w/:id | O visualizador. Descriptografa no lado do cliente, renderiza em sandbox. |
GET /p/:id | Um workspace público, como documento simples — em vnshcontent.dev. |
POST /api/drop | Blob de uso único (v1). ?ttl= e ?price=. |
GET /api/blob/:id | Ler um blob de uso único. |
GET /llms.txt | O protocolo, escrito para agentes. |
Escritas respondem 428 sem If-Match, 412 em uma versão desatualizada e 403 em um
token de escrita ruim. Referência completa em docs/api.md.
Modelo de segurança
Contas e artefatos permanentes
Compartilhamento anônimo permanece sem conta e temporário. Entre em
https://account.vnsh.dev com um link mágico para manter workspaces recém-criados
e páginas /artifact/ até você excluí-los. Criações no navegador usam a sessão
conectada automaticamente. Para o CLI, execute vn login e aprove o dispositivo no
seu navegador. MCP e CI podem usar um token de conta em VNSH_TOKEN; o conteúdo ainda é
criptografado localmente para workspaces de link de capacidade, e o banco de dados da conta
armazena apenas seus metadados de propriedade, não chaves ou texto simples.
Durante a pré-visualização gratuita, cada conta pode manter 100 documentos e 1 GB no total,
incluindo versões retidas.
Guarde o link retornado: seu fragmento é a única cópia do segredo de descriptografia/edição,
então a conta pode gerenciar retenção e exclusão, mas não pode recuperar uma
chave perdida.
Artefatos de conta da Fase 1 adicionam um modo de colaboração separado: humanos autenticados e tokens de Agente podem descobrir e versionar conteúdo privado de Artefato sem carregar uma chave de fragmento. Essa conveniência tem um limite de segurança diferente — o vnsh pode tecnicamente ler o conteúdo de Artefatos de conta. Nunca é substituído silenciosamente por um workspace criptografado anônimo, e apenas um humano pode aprovar ou publicar por padrão.
vn login
vn artifact create report.md --title "Release report" --type report
vn artifact list --query release --status draft
vn artifact read <artifact-id>
vn artifact update <artifact-id> report.md --base-version 1 --change-summary "Verified production"
Adicione --json a qualquer comando de Artefato quando outro programa ou Agente consumir o
resultado.
O que se sustenta. O vnsh não pode ler conteúdo criptografado, não pode escrever nele e não pode recuperar um token de escrita de nada que armazena. Conteúdo renderizado roda com sem acesso de mesma origem e sem rede, então um documento hostil não pode alcançar a chave nem enviar nada para lugar nenhum.
O que não se sustenta.
- Entregar um link a alguém entrega a chave, incluindo o provedor de modelo desse agente. O relógio de 24 horas é o que limita isso, não a criptografia — e cada escrita o reinicia, então um workspace editado diariamente permanece vivo.
- O limite é o cliente, não o transporte. O que criptografa detém seu
texto simples primeiro, e tanto o servidor MCP quanto o CLI fazem isso.
npx -ybusca novamente a versão publicada mais recente a cada início; fixe-a (vnsh-mcp@1.8.2), instale-a globalmente uma vez, ou compile a partir do código-fonte se você revisar o que executa. - Um workspace público é legível pelo vnsh, por design. Esse é o nível.
- Metadados não são privados. Horários, tamanhos e endereços existem para qualquer serviço hospedado. Apenas o conteúdo não é.
Self-hosting
Cloudflare Workers mais um bucket R2. Sem banco de dados, sem KV.
git clone https://github.com/raullenchai/vnsh.git
cd vnsh/worker && npm install
wrangler r2 bucket create vnsh-store
wrangler deploy
wrangler.toml vincula R2, dois limitadores de taxa nativos e um conjunto de dados
do Analytics Engine. Versões anteriores usavam um namespace KV para metadados e contadores; foi
removido depois que o limite de escrita do nível gratuito derrubou o site inteiro, e nada
precisa disso agora — se você está seguindo um guia mais antigo que manda criar um, não
precisa. Veja docs/self-hosting.md.
Repositório
| Caminho | O que é |
|---|---|
worker/ | Cloudflare Worker: API, visualizador, página inicial, llms.txt |
mcp/ | vnsh-mcp — o servidor MCP que os agentes usam |
cli/npm/ | vnsh — o comando vn |
cli/ | install.sh e a função de shell sem dependências |
extension/ | Extensão do Chrome |
docs/ | Arquitetura, API, CLI, MCP, operações, self-hosting |
docs/plans/ | Documentos de design, incluindo o plano do workspace v2 |
npm test # every package
cd worker && npm run dev # local worker
Quatro pacotes carregam sua própria cópia da agenda de chaves, porque são distribuídos independentemente. Cada um é fixado aos mesmos vetores de teste: um link feito por um que não abrirá em outro é lido como corrupção em vez de divergência de versão, então a falha seria silenciosa. Se você mudar uma derivação, esses testes são o que impede que isso aconteça silenciosamente.
Contribuindo
Issues e pull requests são bem-vindos, inclusive aqueles que nos dizem que estamos errados —
a contribuição mais útil até agora foi alguém reimplementando o protocolo a partir de
llms.txt e relatando tudo o que o documento deixou de dizer.
Comece por CONTRIBUTING.md. Ele cobre as duas armadilhas neste codebase que pegam todo mundo: o código do lado do cliente do worker vive dentro de um template literal, então barras invertidas devem ser duplicadas e um backtick perdido encerra a string cem linhas antes de onde o compilador reclama.
Encontrou um problema de segurança? Por favor, não abra uma issue pública — SECURITY.md tem o formulário privado e lista o que é declarado e o que deliberadamente não é.
Licença
MIT — veja LICENSE.