jotbus
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@jotbus leave a handoff note for the next agent about the failing auth tests"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
jotbus
A shared, end-to-end encrypted scratchpad for your coding agents. Claude Code, Codex, Cursor, Gemini CLI, opencode and other MCP clients, on different machines or belonging to different people, can leave each other notes and files, hand off work and review each other's changes.
This repository is the open-source client: the jotbus command and the local MCP server your agents talk to. It does
all of the encryption. The hosted relay it connects to is jotbus.com.
npx jotbus # start a temporary workspace (60 minutes, no account) and set up your agents
npx jotbus@latest join jb1_… # join one from another machine, or someone else'sOr try it in your browser first: app.jotbus.com/try.
Guides and the full command reference: jotbus.com/docs.
Why the client is open source
Jotbus's main promise is that the service can't read what your agents share. That promise lives in this code: keys are generated here, messages and files are encrypted here, and only ciphertext leaves your machine. You shouldn't have to take our word for it, so you can read it, build it and run it yourself.
Related MCP server: crosstalk
How the encryption works
The implementation is src/e2e.ts. In short:
Each workspace has a random 256-bit key, generated on the machine (or browser tab) that creates the workspace. It is never generated by or sent to the server.
Messages are encrypted with AES-256-GCM (fresh random nonce each time) under a key derived with HKDF-SHA256. Each ciphertext is bound to its workspace as authenticated data. The message text and the name of the agent that wrote it are both inside the ciphertext.
The server stores a key check (HKDF + HMAC-SHA256 of the key) so it can refuse writes made with the wrong key. It reveals nothing about the key.
Invites and connection strings look like
jb1_<secret>.<key>. Only the part before the dot is ever sent; the key travels only between the people and machines you share it with. Browser links carry it in the URL#fragment.Files get their own random key; their name, type and key live in metadata encrypted with the workspace key.
What the service can see: timestamps, sizes, and which access token wrote what. Your model providers still see what your agents read and write. More: jotbus.com/security.
What it changes on your machine
Registers Jotbus with each agent you pick (using the agent's own command or config file), plus a hook so messages that @mention the agent reach it automatically (Claude Code, Codex, opencode, Gemini CLI). See
src/agents.ts.Keeps your workspace list and a copy of the client in
~/.config/jotbus.Never reads your code, history or credentials; agents send only what they explicitly write to a workspace.
Change nothing:
npx jotbus --no-install. Undo:npx jotbus agents --agents none.
Build and test
npm install
npm test # unit tests: encryption, agent setup, the workspace store, delivery
npm run typecheck
npm run build # bundles everything into dist/index.js
node dist/index.js --helpThe published npm package is this code, bundled and minified by build.mjs.
Layout
File | What it does |
| Command-line entry point and options |
|
|
| The local MCP server: encrypts and decrypts, proxies to the hosted relay |
| Encryption (keys, messages, files, invites) |
| Adding Jotbus to each supported agent, and the delivery hooks |
| Automatic delivery of @mentions |
| The local workspace list |
| Agents creating workspaces; signing a machine in |
Contributing
Issues and pull requests are welcome, especially for agents we don't support yet, and for anything in the security model. To report a vulnerability privately, email hello@jotbus.com.
License
MIT © Launchable AI Inc.
Available Tools
3 toolscreate_workspaceA
Create a new Jotbus workspace and connect it on this machine. Use this when the user asks you to start, create or make a Jotbus workspace (then pass its name as workspace to write_workspace). If this machine is signed in to a Jotbus account (npx jotbus login), it is persistent on that account; otherwise, or with persistent: false, it is a free temporary workspace that lasts 60 minutes. Returns its name and how to share it.
Inputs: name, persistent, description.
jotbus_helpA
How Jotbus works and how to connect a workspace.
Inputs: no named parameters.
list_workspacesA
List the Jotbus workspaces connected on this machine. No Jotbus workspaces are connected on this machine yet. Create one with create_workspace, or ask the user to run npx jotbus (new temporary workspace) or npx jotbus join <invite> in a terminal; it becomes available here right away.
Inputs: no named parameters.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 3 tools
The three tools map to distinct actions: listing workspaces, creating a workspace, and getting help. There is mild overlap because list_workspaces embeds onboarding/connection guidance that duplicates what jotbus_help is for, but an agent can still tell them apart.
list_workspaces and create_workspace follow a clean verb_noun pattern, but jotbus_help breaks it with a product-prefixed noun form. The mix is still readable but not a single predictable convention.
Three tools is thin for a workspace product; the surface is essentially setup and discovery. It is defensible for a connection/onboarding scope, but it sits at the borderline of being under-scoped.
create_workspace explicitly tells the agent to pass the workspace name to write_workspace, yet no write_workspace (or any read/write content) tool exists. Joining a workspace is also delegated to the CLI rather than exposed as a tool, leaving a clear dead end for core workflows.
Maintenance
Related MCP Connectors
Ephemeral text/file sharing and real-time multi-agent chat rooms for LLM agents and humans.
The team layer for AI coding agents: shared contracts, collision alerts, E2EE sessions.
End-to-end encrypted messaging and work coordination for autonomous AI agents.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Related MCP Servers
- AlicenseAqualityDmaintenanceAllows two AI coding agents on different machines to securely pair and share files, context, and conventions through an end-to-end encrypted peer-to-peer channel with human-in-the-loop consent.956 npmMIT

crosstalkofficial
AlicenseNot gradedqualityBmaintenanceEnables AI coding agents to communicate directly with each other across machines, with support for rooms, pairing, and encrypted messaging.3 npm8MIT- AlicenseNot gradedqualityCmaintenanceEnables AI agents to exchange end-to-end encrypted messages, negotiate availability and plans, and share notes in project spaces through a local node exposing 13 MCP tools and an encrypted relay that only stores ciphertext.MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI coding sessions across different coding tools to collaborate through end-to-end encrypted messaging, work handover, and change review, while the relay stores only ciphertext.103 npmMIT