Bundle files and their context into one portable archive. Move it to any tool, any repo, any machine, any teammate. They unpack the files — plus the brief that explains what to do with them.
Before maps, before GPS — travelers marked trees to signal a way through. Three cuts meant: someone has been here. Follow this.
The mark wasn't about the traveler. It was about whoever came next — a way to carry knowledge forward through unfamiliar terrain, without having to be there to explain it.
The problem hasn't changed. You move work across tools, sessions, projects, repos. Context doesn't travel on its own. Right now, you carry it by hand.
A solo founder running three repos across four AI tools. Conventions from one project that should carry to the next. A teammate who needs the files and the brief. The thread that ties it all together doesn't travel on its own.
Re-assembling context by hand is the tax you pay every time you switch tools, switch repos, or start something new.
3Notch packages files and the context to use them into one portable archive. Code, docs, images, conventions, briefs, decisions — whatever the next side needs. The receiver unpacks the files and reads the brief you wrote on top.
No vector database. No cloud relay. No hidden scraping. The contents are what you put in. Nothing more.
And what you pack stays. Every notch joins your local trail — indexed, queryable, available next session, next project, next tool.
A single loop that maps onto every cross-tool, cross-repo, cross-machine handoff.
Code, docs, images, conventions, next steps — whatever the other side needs. One command captures the bytes and the context that uses them.
$ notch packet create \ --title "Launch page handoff" \ --file index.html \ --file favicon.svg
Lands as a folder under .notch/outbox/ — Markdown brief, manifest, copied files. Pack it into a single .notchpkt archive when you need to move it.
$ notch packet pack a7f3 → a7f3.notchpkt 6.1kb · sha256 verified
Send the archive through any channel — scp, email, Slack, AirDrop, git. The receiver unpacks the files and reads your brief. No AI tool required to read.
$ notch packet unpack a7f3.notchpkt ✓ files restored ✓ brief: see packet.md
The packet moves. The notch stays. Each handoff also lands in your local trail — indexed, queryable, available the next time you need it.
Summaries lose fidelity. Packets carry the actual files alongside the reasoning, so the receiving tool doesn't have to guess.
Every packet is a folder with packet.md, manifest.json, and copied artifacts. Diff it, grep it, review it — then hand it off.
notch packet preview shows exactly what the next agent will read.$ notch packet create \ --title "Brand handoff" \ --summary "Brand handoff for the launch page." \ --to-agent codex \ --to-repo ../brand-site \ --file mascot.jpg:asset \ --file showcase.html:source \ --next-steps "Build apps/brand-site/ using showcase.html." scanning artifacts for secrets... writing .notch/outbox/a7f3.brand-handoff/ ├─ packet.md 312 tokens ├─ manifest.json sha256 verified └─ artifacts/ 2 files · 4.2kb ✓ Notch marked. outbox/a7f3.brand-handoff
A local stdio MCP server exposes the same record surface the CLI uses. Wire Claude Code, Claude Desktop, Cursor, or Codex — and prompt in natural language. Your agent calls notch for you.
When the source agent creates a packet, the destination agent lists and reads it immediately. No upload, no relay, no waiting.
get_packet, list_packets, get_brief, get_status.create_packet, create_mark, create_reply, import_packet..notch/private/ stays hidden unless you start the server with --include-private.$ notch onboard --yes --mcp claude-code ✓ created .notch/ ✓ wired ~/.claude/mcp.json → notch mcp serve $ notch onboard --yes --mcp claude-desktop ✓ wired Claude Desktop config → same .notch/ store $ notch mcp serve 3notch v0.4.0 · stdio · store .notch/ read: get_packet · list_packets · get_brief · ... write: create_packet · create_mark · create_reply · ... private: hidden (use --include-private) ▌ ready · waiting for client
A deterministic .notchpkt archive moves through whatever channel you already trust — scp, iCloud, Tailscale, email, git LFS.
A gzipped tar with deterministic entry ordering. Hashes are re-verified at unpack against the manifest before anything lands in the inbox.
$ notch packet pack a7f3 → a7f3.notchpkt · 6.1kb · sha256:9c2…f4d # move via your channel of choice $ scp a7f3.notchpkt other-host:~/inbox/ # on the destination $ notch packet unpack a7f3.notchpkt ✓ verified manifest · sha256 match ✓ imported .notch/inbox/a7f3.brand-handoff/ $ notch packet preview a7f3 from: claude-desktop@laptop · 4m ago next: Build apps/brand-site/ using showcase.html
Every notch you leave joins a growing, structured, queryable record of how you work. Pack a packet, leave a mark, reply to a thread — it all gets indexed. The corpus is yours, locally, in plain files.
Every packet, mark, and reply lands with explicit relationships — supersedes, replyTo, refs. A deterministic edge index keeps the corpus queryable as it grows. No LLM judgment, no inference, no magic.
supersedes — explicit edges to prior versions. Decisions update; the trail keeps the history.relationships.json — deterministic edge index, derived from the records. Queryable by any tool.notch check — structural integrity. Broken supersedes, cycles, self-reference — caught before the corpus drifts.notch scan — secret scanner. Packets land clean or not at all.$ notch status store .notch/ · 21 records · 127kb packets 12 · marks 7 · replies 4 edges 18 · supersedes 5 · replies 6 · refs 7 $ notch check ├─ packets 12 ok ├─ relationships 18 edges resolved ├─ supersedes no cycles └─ replyTo all targets exist ✓ corpus is structurally sound. $ cat .notch/index/relationships.json { "schemaVersion": "0.4.0", "edges": [ { from: "a7f3", to: "b1c2", kind: "supersedes" }, { from: "d4e5", to: "a7f3", kind: "replyTo" }, { from: "f6a8", to: "d4e5", kind: "ref" }, … ] }
One command to install. Node 20+. Works in any repo, on any project, right now.
A packet is a folder of Markdown plus the actual file bytes. Anything that opens a file can read it. AI clients just give the AI an ergonomic way to consume the same packet humans already can.
The brief is a packet.md file. Vim, VS Code, Notepad — they all open it.
Browse artifacts/ for the actual files. They're byte-identical to what you packed.
The archive is a gzipped tar. tar -xzf packet.notchpkt works without installing anything.
Three months later, in a different project. cat packet.md. Done.
Wired via notch onboard --mcp claude-code. Reads and writes the store directly.
Same store, second client. Hand off without leaving the desktop app.
Any MCP-capable agent points at the local store and reads packets through the same tool surface.
Browser chats can't reach local MCP yet. Fallback: pbpaste | notch packet import -.
Tight scope, not a feature list. Each verb does one thing and stays out of the way.
Initialize .notch/ and wire MCP clients in one step.
Bundle files, refs, and intent. The core verb.
Read a packet folder or .notchpkt archive into the inbox.
See exactly what the next agent will read — before relying on it.
Hash-verified .notchpkt archives for cross-machine transport.
Scoped task briefs for narrow agent runs.
Self-addressed private capture. The fastest way to remember something for yourself.
Typed replies that thread back to the originating packet.
Carry preferences and conventions into a new repo without leaking the old one.
Print client-specific instruction packs for web chats and constrained surfaces.
Standalone secret scanner over any file or stdin.
Deterministic structural checks and store diagnostics. No magic.
The product stays narrow on purpose. These boundaries are tested by a regression-guard in the repo.
lint. The substrate ships — records, relationships, integrity checks. Surfaces on top (readers, browsers, agent integrations) are yours or any contributor's. Anything that needs semantic judgment lives outside the core.What the page didn't already answer.
Same-repo, same-tool continuity is already solved — by CLAUDE.md, native tool memory, and git commit. 3Notch's wedge is everything that crosses a boundary: handing files from one tool to another, carrying conventions from an old project into a new one, sending a teammate the files and the brief, picking up where you left off on a different machine.
If your work stays in one tool on one repo, you probably don't need 3Notch. If you're juggling multiple repos and tools — or you're starting a new project and want your conventions, skills, and workflows to come with you — that's the gap.
No. A .notchpkt archive is a standard gzipped tar. Anyone with tar can extract it and get the files back plus a Markdown brief they can read in any editor.
Installing the notch CLI on the receiving side just gives you the ergonomic verbs — notch packet unpack hash-verifies the manifest before extracting, notch packet preview formats the brief, notch packet import organizes it into the local store. Useful, not required.
Only when you move them. 3Notch writes Markdown packets to a local .notch/ store. There is no upload, no hosted relay, no account, no telemetry. The CLI never makes a network request unless you explicitly invoke a transport command.
For cross-machine handoff, you run notch packet pack, get a .notchpkt file, and move it through whatever channel you already trust.
The CLI is the primary surface. MCP is an optional convenience for clients that speak it. You can notch packet create from any terminal, hand the resulting folder to anything that reads Markdown, and never touch MCP.
For browser chats (Claude.ai, ChatGPT), there's a clipboard-mediated fallback: notch prompt --client claude-chat prints an instruction pack you paste in; the chat returns a packet you import with pbpaste | notch packet import -.
They accumulate into a local corpus. Every packet, mark, and reply lands in .notch/ as a Markdown record and gets indexed into .notch/index/relationships.json — a deterministic edge graph over your decisions, supersedes, and replies. notch check catches broken references and cycles before the corpus drifts.
3Notch ships the substrate, not the surface. There's no built-in wiki UI, browse view, or agent integration on top. Whether you grep the records, point an agent at them, or build a personal wiki on the index is up to you. The corpus is plain files; it stays portable.
MIT. Free. No tiers, no hosted service, no upsell. 3Notch is open source because the cross-vendor handoff problem can only be solved neutrally — anything else recreates the lock-in it's meant to escape.
One command. Local-first. No account required.