Home

Jump to bottom
Denys Kashkovskyi edited this page Jul 23, 2026 · 7 revisions

Home

Threadnote lets one engineer's coding agent publish a durable project decision that another engineer's different agent can recall. Alice can capture an API contract with Codex; Bob can auto-sync and read it from Claude Code, Cursor, or Copilot during the next task.

That cross-user, cross-agent path is the product's main value. Persistent personal memory is the foundation, not the destination.

Alice + Codex ──publish curated memory──▶ team Git repo
│
auto-sync on recall
▼
Bob + Claude Code / Cursor / Copilot

Personal handoffs, preferences, incidents, and unpublished memories stay local. Only curated durable knowledge or reusable artifacts that a user explicitly publishes enter the team Git repo, after preview and secret scanning.

What breaks without it

  • Useful discoveries stay trapped in one person's chat or one vendor's project.
  • Each coding agent has its own context. Switching users or vendors means starting over.
  • Persistence alone creates better private silos; it does not make project knowledge portable to a teammate's agent.
  • Markdown notes are passive. The agent still has to know which note matters now, whether it is stale, and where to write the next handoff.
  • CLAUDE.md / AGENTS.md is per-repo and static. It cannot carry an in-flight feature's design decisions across sessions, much less across agents or repos.
  • Team knowledge stays in DMs. A decision made in a Slack thread never reaches a teammate's agent.

Different from native AI memory

ChatGPT, Gemini, and Claude provide useful continuity inside their own products. ChatGPT and Claude support shared projects; Gemini can share Gems and chats. Threadnote solves a different boundary: a team can keep explicit engineering knowledge in Markdown and Git, then let each developer use it from a supported coding agent without standardizing on one AI vendor.

ThreadnoteNative memory / vendor collaboration spaces
ReachAcross users, machines, and supported coding-agent vendorsInside the provider's account, app, shared project, or Gem
Team source of truthUser-controlled Markdown and GitProvider-hosted chats, files, memory, and settings
Knowledge unitExplicit durable/handoff/archive record with a stable URIProvider-managed memory, project, Gem, or conversation
Recall pathLocal semantic index returns URI candidates; agents read selected recordsProvider-managed retrieval and search
Sharing boundaryPublish selected durable knowledge; personal working state localMembership, links, and controls within the provider
Best fitEngineering teams using multiple agents in real repositoriesContinuity and collaboration inside one AI product

See Threadnote vs Native AI Memory for a product-by-product comparison and links to the official documentation.

What you get

  • One engineer's learning reaches every teammate's agent. Shared memories auto-sync before normal recall/read calls.
  • The team does not have to choose one agent vendor. Codex, Claude Code, Cursor, and Copilot use one MCP workflow.
  • Sharing is explicit and reviewable. Preview, scrub, commit, and push only selected durable memories or artifacts.
  • Private working state stays private. Personal handoffs and unpublished context remain on the local machine.
  • Recall is local and context-efficient. A local embedding model ranks semantic matches, then the agent reads only the selected viking:// records instead of replaying the full memory history.
  • Fresh agents start with recall, not amnesia. A new session can read the latest handoff before touching code.
  • Compaction becomes a checkpoint, not memory loss. Durable facts and current status survive the summary.
  • Agent switching stops resetting the task. Codex can leave a handoff that Claude Code, Cursor, or Copilot can read.
  • Cross-repo work stops scattering context. Worksets let you recall related repos together, such as a mobile app, web app, and shared library.
  • Handoffs can carry review state. PR, issue, CI, blockers, next steps, and referenced memories stay attached to the current work log.
  • Repo docs stay clean.AGENTS.md, CLAUDE.md, and docs remain stable policy; threadnote carries living context.
  • Team context is explicit. Publish only curated durable memories to a team git repo; personal handoffs stay local.

Why not just Markdown files?

Use Markdown files. threadnote makes them operational.

  • AGENTS.md / CLAUDE.md / repo docs: stable, reviewed, version-controlled rules.
  • Random notes: easy to write, hard for agents to rank, scope, update, or know when stale.
  • threadnote memories: Markdown on disk plus semantic recall, stable URIs, lifecycle (durable, handoff, archived), scoped compaction, MCP tools, and safe team sharing.

The source of truth is still local files. The benefit is that agents know how to find the right file, decide whether it is current, update it without creating duplicates, and hand it to the next agent. By default, OpenViking builds the semantic index locally with a GGUF embedding model through llama.cpp, so the memory corpus does not need to be sent to a hosted embedding service for recall.

Agent perspective

These are workflow examples from an agent's point of view, not external endorsements.

Codex before threadnote: "I inspect the repo, ask what changed, rediscover the test command, and hope the compacted chat summary did not drop the important caveat."

Codex with threadnote: "I recall the branch handoff and durable feature memory first. I can name the files touched, the last failing check, the design decision behind the code, and the next step before editing."

Claude Code before threadnote: "A long debugging thread compacts into a vague narrative. The next turn knows the arc, but not the exact command, blocker, or decision."

Claude Code with threadnote: "The pre-compact handoff captures the concrete state. The next session reads the same memory and continues without asking the user to reconstruct it."

Cross-repo work with threadnote: "I recall the mobile_web workset once and see the relevant handoffs, seeded guidance, and dependency facts for both apps before changing either one."

Quickstart

curl -fsSL https://raw.githubusercontent.com/Kashkovsky/threadnote/main/scripts/install.sh | sh
threadnote mcp-install claude --apply # or codex / cursor / copilot
threadnote doctor --dry-run

The default MCP registration exposes six common tools; the CLI remains available for every advanced workflow. Open a fresh agent session after installing MCP so the new server registration loads.

Explore the wiki

  • Installation — the one-line installer, manual install, runtime overrides, and updates.
  • Configuration — environment variables, THREADNOTE_HOME, host/port, and the seed manifest.
  • Architecture — how the stdio MCP adapter, openviking-server, the viking:// URI scheme, and on-disk storage fit together.
  • Threadnote vs Native AI Memory — why portable team memory is different from ChatGPT, Gemini, and Claude memory.
  • Memory Lifecycle — durable vs handoff, active vs archived, project/topic paths, and compaction.
  • Recall and Read — searching context, reading and listing viking:// URIs, and scope inference.
  • Seeding Repos and Skills — curated manifest seeding for repo guidance, worksets, dependency facts, docs, and SKILL.md catalogs.
  • Sharing Memories — publishing curated durable memories to a team git repo and syncing teammates' updates.
  • Safety and Security — local-by-default writes, ignore rules, redaction, secret scanning, and explicit config changes.
  • CLI Reference — every threadnote command and its flags.
  • Web Manager — the local web UI (threadnote manage) for browsing, editing, and managing memories.
  • Agent Instructions — the user-level guidance installed for Codex, Claude, Cursor, and Copilot, plus Claude Code hooks.
  • Migration — moving an existing repo workflow onto threadnote and migrating legacy memories.
  • Troubleshooting — diagnosing install, health, MCP, and server problems.
  • Concepts and FAQ — core terms and common questions.

Links

License: AGPL-3.0-or-later. Built on OpenViking 0.3.24. Requires Node.js >= 20.

See also: Installation, Architecture, Concepts and FAQ.

GitHub · npm · walkthrough deck · OpenViking · AGPL-3.0-or-later

threadnote

Start here

Concepts

Workflows

Reference

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Home
Jump to bottom

Denys Kashkovskyi edited this page Jul 23, 2026
·
7 revisions
Home
Threadnote lets one engineer's coding agent publish a durable project decision that another engineer's different agent
can recall. Alice can capture an API contract with Codex; Bob can auto-sync and read it from Claude Code, Cursor, or
Copilot during the next task.
That cross-user, cross-agent path is the product's main value. Persistent personal memory is the foundation, not the
destination.
Alice + Codex ──publish curated memory──▶ team Git repo
│
auto-sync on recall
▼
Bob + Claude Code / Cursor / Copilot

Personal handoffs, preferences, incidents, and unpublished memories stay local. Only curated durable knowledge or
reusable artifacts that a user explicitly publishes enter the team Git repo, after preview and secret scanning.
What breaks without it
  • Useful discoveries stay trapped in one person's chat or one vendor's project.
  • Each coding agent has its own context. Switching users or vendors means starting over.
  • Persistence alone creates better private silos; it does not make project knowledge portable to a teammate's agent.
  • Markdown notes are passive. The agent still has to know which note matters now, whether it is stale, and where to write the next handoff.
  • CLAUDE.md / AGENTS.md is per-repo and static. It cannot carry an in-flight feature's design decisions across sessions, much less across agents or repos.
  • Team knowledge stays in DMs. A decision made in a Slack thread never reaches a teammate's agent.
Different from native AI memory
ChatGPT, Gemini, and Claude provide useful continuity inside their own products. ChatGPT and Claude support shared
projects; Gemini can share Gems and chats. Threadnote solves a different boundary: a team can keep explicit engineering
knowledge in Markdown and Git, then let each developer use it from a supported coding agent without standardizing on
one AI vendor.
ThreadnoteNative memory / vendor collaboration spaces
ReachAcross users, machines, and supported coding-agent vendorsInside the provider's account, app, shared project, or Gem
Team source of truthUser-controlled Markdown and GitProvider-hosted chats, files, memory, and settings
Knowledge unitExplicit durable/handoff/archive record with a stable URIProvider-managed memory, project, Gem, or conversation
Recall pathLocal semantic index returns URI candidates; agents read selected recordsProvider-managed retrieval and search
Sharing boundaryPublish selected durable knowledge; personal working state localMembership, links, and controls within the provider
Best fitEngineering teams using multiple agents in real repositoriesContinuity and collaboration inside one AI product
See Threadnote vs Native AI Memory for a product-by-product comparison and links to the official documentation.
What you get
  • One engineer's learning reaches every teammate's agent. Shared memories auto-sync before normal recall/read calls.
  • The team does not have to choose one agent vendor. Codex, Claude Code, Cursor, and Copilot use one MCP workflow.
  • Sharing is explicit and reviewable. Preview, scrub, commit, and push only selected durable memories or artifacts.
  • Private working state stays private. Personal handoffs and unpublished context remain on the local machine.
  • Recall is local and context-efficient. A local embedding model ranks semantic matches, then the agent reads only
the selected viking:// records instead of replaying the full memory history.
  • Fresh agents start with recall, not amnesia. A new session can read the latest handoff before touching code.
  • Compaction becomes a checkpoint, not memory loss. Durable facts and current status survive the summary.
  • Agent switching stops resetting the task. Codex can leave a handoff that Claude Code, Cursor, or Copilot can read.
  • Cross-repo work stops scattering context. Worksets let you recall related repos together, such as a mobile app, web app, and shared library.
  • Handoffs can carry review state. PR, issue, CI, blockers, next steps, and referenced memories stay attached to the current work log.
  • Repo docs stay clean.AGENTS.md, CLAUDE.md, and docs remain stable policy; threadnote carries living context.
  • Team context is explicit. Publish only curated durable memories to a team git repo; personal handoffs stay local.
Why not just Markdown files?
Use Markdown files. threadnote makes them operational.
  • AGENTS.md / CLAUDE.md / repo docs: stable, reviewed, version-controlled rules.
  • Random notes: easy to write, hard for agents to rank, scope, update, or know when stale.
  • threadnote memories: Markdown on disk plus semantic recall, stable URIs, lifecycle (durable, handoff, archived), scoped compaction, MCP tools, and safe team sharing.
The source of truth is still local files. The benefit is that agents know how to find the right file, decide whether it is current, update it without creating duplicates, and hand it to the next agent.
By default, OpenViking builds the semantic index locally with a GGUF embedding model through llama.cpp, so the memory
corpus does not need to be sent to a hosted embedding service for recall.
Agent perspective
These are workflow examples from an agent's point of view, not external endorsements.
Codex before threadnote: "I inspect the repo, ask what changed, rediscover the test command, and hope the compacted chat summary did not drop the important caveat."
Codex with threadnote: "I recall the branch handoff and durable feature memory first. I can name the files touched, the last failing check, the design decision behind the code, and the next step before editing."
Claude Code before threadnote: "A long debugging thread compacts into a vague narrative. The next turn knows the arc, but not the exact command, blocker, or decision."
Claude Code with threadnote: "The pre-compact handoff captures the concrete state. The next session reads the same memory and continues without asking the user to reconstruct it."
Cross-repo work with threadnote: "I recall the mobile_web workset once and see the relevant handoffs, seeded guidance, and dependency facts for both apps before changing either one."
Quickstart
curl -fsSL https://raw.githubusercontent.com/Kashkovsky/threadnote/main/scripts/install.sh | sh
threadnote mcp-install claude --apply # or codex / cursor / copilot
threadnote doctor --dry-run
The default MCP registration exposes six common tools; the CLI remains available for every advanced workflow. Open a fresh agent session after installing MCP so the new server registration loads.
Explore the wiki
  • Installation — the one-line installer, manual install, runtime overrides, and updates.
  • Configuration — environment variables, THREADNOTE_HOME, host/port, and the seed manifest.
  • Architecture — how the stdio MCP adapter, openviking-server, the viking:// URI scheme, and on-disk storage fit together.
  • Threadnote vs Native AI Memory — why portable team memory is different from ChatGPT, Gemini, and Claude memory.
  • Memory Lifecycle — durable vs handoff, active vs archived, project/topic paths, and compaction.
  • Recall and Read — searching context, reading and listing viking:// URIs, and scope inference.
  • Seeding Repos and Skills — curated manifest seeding for repo guidance, worksets, dependency facts, docs, and SKILL.md catalogs.
  • Sharing Memories — publishing curated durable memories to a team git repo and syncing teammates' updates.
  • Safety and Security — local-by-default writes, ignore rules, redaction, secret scanning, and explicit config changes.
  • CLI Reference — every threadnote command and its flags.
  • Web Manager — the local web UI (threadnote manage) for browsing, editing, and managing memories.
  • Agent Instructions — the user-level guidance installed for Codex, Claude, Cursor, and Copilot, plus Claude Code hooks.
  • Migration — moving an existing repo workflow onto threadnote and migrating legacy memories.
  • Troubleshooting — diagnosing install, health, MCP, and server problems.
  • Concepts and FAQ — core terms and common questions.
Links
License: AGPL-3.0-or-later. Built on OpenViking 0.3.24. Requires Node.js >= 20.
See also: Installation, Architecture, Concepts and FAQ.
GitHub · npm · walkthrough deck · OpenViking · AGPL-3.0-or-later
threadnote
Start here
Concepts
Workflows
Reference
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Home
Jump to bottom

Denys Kashkovskyi edited this page Jul 23, 2026
·
7 revisions
Home
Threadnote lets one engineer's coding agent publish a durable project decision that another engineer's different agent
can recall. Alice can capture an API contract with Codex; Bob can auto-sync and read it from Claude Code, Cursor, or
Copilot during the next task.
That cross-user, cross-agent path is the product's main value. Persistent personal memory is the foundation, not the
destination.
Alice + Codex ──publish curated memory──▶ team Git repo
│
auto-sync on recall
▼
Bob + Claude Code / Cursor / Copilot

Personal handoffs, preferences, incidents, and unpublished memories stay local. Only curated durable knowledge or
reusable artifacts that a user explicitly publishes enter the team Git repo, after preview and secret scanning.
What breaks without it
  • Useful discoveries stay trapped in one person's chat or one vendor's project.
  • Each coding agent has its own context. Switching users or vendors means starting over.
  • Persistence alone creates better private silos; it does not make project knowledge portable to a teammate's agent.
  • Markdown notes are passive. The agent still has to know which note matters now, whether it is stale, and where to write the next handoff.
  • CLAUDE.md / AGENTS.md is per-repo and static. It cannot carry an in-flight feature's design decisions across sessions, much less across agents or repos.
  • Team knowledge stays in DMs. A decision made in a Slack thread never reaches a teammate's agent.
Different from native AI memory
ChatGPT, Gemini, and Claude provide useful continuity inside their own products. ChatGPT and Claude support shared
projects; Gemini can share Gems and chats. Threadnote solves a different boundary: a team can keep explicit engineering
knowledge in Markdown and Git, then let each developer use it from a supported coding agent without standardizing on
one AI vendor.
ThreadnoteNative memory / vendor collaboration spaces
ReachAcross users, machines, and supported coding-agent vendorsInside the provider's account, app, shared project, or Gem
Team source of truthUser-controlled Markdown and GitProvider-hosted chats, files, memory, and settings
Knowledge unitExplicit durable/handoff/archive record with a stable URIProvider-managed memory, project, Gem, or conversation
Recall pathLocal semantic index returns URI candidates; agents read selected recordsProvider-managed retrieval and search
Sharing boundaryPublish selected durable knowledge; personal working state localMembership, links, and controls within the provider
Best fitEngineering teams using multiple agents in real repositoriesContinuity and collaboration inside one AI product
See Threadnote vs Native AI Memory for a product-by-product comparison and links to the official documentation.
What you get
  • One engineer's learning reaches every teammate's agent. Shared memories auto-sync before normal recall/read calls.
  • The team does not have to choose one agent vendor. Codex, Claude Code, Cursor, and Copilot use one MCP workflow.
  • Sharing is explicit and reviewable. Preview, scrub, commit, and push only selected durable memories or artifacts.
  • Private working state stays private. Personal handoffs and unpublished context remain on the local machine.
  • Recall is local and context-efficient. A local embedding model ranks semantic matches, then the agent reads only
the selected viking:// records instead of replaying the full memory history.
  • Fresh agents start with recall, not amnesia. A new session can read the latest handoff before touching code.
  • Compaction becomes a checkpoint, not memory loss. Durable facts and current status survive the summary.
  • Agent switching stops resetting the task. Codex can leave a handoff that Claude Code, Cursor, or Copilot can read.
  • Cross-repo work stops scattering context. Worksets let you recall related repos together, such as a mobile app, web app, and shared library.
  • Handoffs can carry review state. PR, issue, CI, blockers, next steps, and referenced memories stay attached to the current work log.
  • Repo docs stay clean.AGENTS.md, CLAUDE.md, and docs remain stable policy; threadnote carries living context.
  • Team context is explicit. Publish only curated durable memories to a team git repo; personal handoffs stay local.
Why not just Markdown files?
Use Markdown files. threadnote makes them operational.
  • AGENTS.md / CLAUDE.md / repo docs: stable, reviewed, version-controlled rules.
  • Random notes: easy to write, hard for agents to rank, scope, update, or know when stale.
  • threadnote memories: Markdown on disk plus semantic recall, stable URIs, lifecycle (durable, handoff, archived), scoped compaction, MCP tools, and safe team sharing.
The source of truth is still local files. The benefit is that agents know how to find the right file, decide whether it is current, update it without creating duplicates, and hand it to the next agent.
By default, OpenViking builds the semantic index locally with a GGUF embedding model through llama.cpp, so the memory
corpus does not need to be sent to a hosted embedding service for recall.
Agent perspective
These are workflow examples from an agent's point of view, not external endorsements.
Codex before threadnote: "I inspect the repo, ask what changed, rediscover the test command, and hope the compacted chat summary did not drop the important caveat."
Codex with threadnote: "I recall the branch handoff and durable feature memory first. I can name the files touched, the last failing check, the design decision behind the code, and the next step before editing."
Claude Code before threadnote: "A long debugging thread compacts into a vague narrative. The next turn knows the arc, but not the exact command, blocker, or decision."
Claude Code with threadnote: "The pre-compact handoff captures the concrete state. The next session reads the same memory and continues without asking the user to reconstruct it."
Cross-repo work with threadnote: "I recall the mobile_web workset once and see the relevant handoffs, seeded guidance, and dependency facts for both apps before changing either one."
Quickstart
curl -fsSL https://raw.githubusercontent.com/Kashkovsky/threadnote/main/scripts/install.sh | sh
threadnote mcp-install claude --apply # or codex / cursor / copilot
threadnote doctor --dry-run
The default MCP registration exposes six common tools; the CLI remains available for every advanced workflow. Open a fresh agent session after installing MCP so the new server registration loads.
Explore the wiki
  • Installation — the one-line installer, manual install, runtime overrides, and updates.
  • Configuration — environment variables, THREADNOTE_HOME, host/port, and the seed manifest.
  • Architecture — how the stdio MCP adapter, openviking-server, the viking:// URI scheme, and on-disk storage fit together.
  • Threadnote vs Native AI Memory — why portable team memory is different from ChatGPT, Gemini, and Claude memory.
  • Memory Lifecycle — durable vs handoff, active vs archived, project/topic paths, and compaction.
  • Recall and Read — searching context, reading and listing viking:// URIs, and scope inference.
  • Seeding Repos and Skills — curated manifest seeding for repo guidance, worksets, dependency facts, docs, and SKILL.md catalogs.
  • Sharing Memories — publishing curated durable memories to a team git repo and syncing teammates' updates.
  • Safety and Security — local-by-default writes, ignore rules, redaction, secret scanning, and explicit config changes.
  • CLI Reference — every threadnote command and its flags.
  • Web Manager — the local web UI (threadnote manage) for browsing, editing, and managing memories.
  • Agent Instructions — the user-level guidance installed for Codex, Claude, Cursor, and Copilot, plus Claude Code hooks.
  • Migration — moving an existing repo workflow onto threadnote and migrating legacy memories.
  • Troubleshooting — diagnosing install, health, MCP, and server problems.
  • Concepts and FAQ — core terms and common questions.
Links
License: AGPL-3.0-or-later. Built on OpenViking 0.3.24. Requires Node.js >= 20.
See also: Installation, Architecture, Concepts and FAQ.
GitHub · npm · walkthrough deck · OpenViking · AGPL-3.0-or-later
threadnote
Start here
Concepts
Workflows
Reference
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Home
Jump to bottom

Denys Kashkovskyi edited this page Jul 23, 2026
·
7 revisions
Home
Threadnote lets one engineer's coding agent publish a durable project decision that another engineer's different agent
can recall. Alice can capture an API contract with Codex; Bob can auto-sync and read it from Claude Code, Cursor, or
Copilot during the next task.
That cross-user, cross-agent path is the product's main value. Persistent personal memory is the foundation, not the
destination.
Alice + Codex ──publish curated memory──▶ team Git repo
│
auto-sync on recall
▼
Bob + Claude Code / Cursor / Copilot

Personal handoffs, preferences, incidents, and unpublished memories stay local. Only curated durable knowledge or
reusable artifacts that a user explicitly publishes enter the team Git repo, after preview and secret scanning.
What breaks without it
  • Useful discoveries stay trapped in one person's chat or one vendor's project.
  • Each coding agent has its own context. Switching users or vendors means starting over.
  • Persistence alone creates better private silos; it does not make project knowledge portable to a teammate's agent.
  • Markdown notes are passive. The agent still has to know which note matters now, whether it is stale, and where to write the next handoff.
  • CLAUDE.md / AGENTS.md is per-repo and static. It cannot carry an in-flight feature's design decisions across sessions, much less across agents or repos.
  • Team knowledge stays in DMs. A decision made in a Slack thread never reaches a teammate's agent.
Different from native AI memory
ChatGPT, Gemini, and Claude provide useful continuity inside their own products. ChatGPT and Claude support shared
projects; Gemini can share Gems and chats. Threadnote solves a different boundary: a team can keep explicit engineering
knowledge in Markdown and Git, then let each developer use it from a supported coding agent without standardizing on
one AI vendor.
ThreadnoteNative memory / vendor collaboration spaces
ReachAcross users, machines, and supported coding-agent vendorsInside the provider's account, app, shared project, or Gem
Team source of truthUser-controlled Markdown and GitProvider-hosted chats, files, memory, and settings
Knowledge unitExplicit durable/handoff/archive record with a stable URIProvider-managed memory, project, Gem, or conversation
Recall pathLocal semantic index returns URI candidates; agents read selected recordsProvider-managed retrieval and search
Sharing boundaryPublish selected durable knowledge; personal working state localMembership, links, and controls within the provider
Best fitEngineering teams using multiple agents in real repositoriesContinuity and collaboration inside one AI product
See Threadnote vs Native AI Memory for a product-by-product comparison and links to the official documentation.
What you get
  • One engineer's learning reaches every teammate's agent. Shared memories auto-sync before normal recall/read calls.
  • The team does not have to choose one agent vendor. Codex, Claude Code, Cursor, and Copilot use one MCP workflow.
  • Sharing is explicit and reviewable. Preview, scrub, commit, and push only selected durable memories or artifacts.
  • Private working state stays private. Personal handoffs and unpublished context remain on the local machine.
  • Recall is local and context-efficient. A local embedding model ranks semantic matches, then the agent reads only
the selected viking:// records instead of replaying the full memory history.
  • Fresh agents start with recall, not amnesia. A new session can read the latest handoff before touching code.
  • Compaction becomes a checkpoint, not memory loss. Durable facts and current status survive the summary.
  • Agent switching stops resetting the task. Codex can leave a handoff that Claude Code, Cursor, or Copilot can read.
  • Cross-repo work stops scattering context. Worksets let you recall related repos together, such as a mobile app, web app, and shared library.
  • Handoffs can carry review state. PR, issue, CI, blockers, next steps, and referenced memories stay attached to the current work log.
  • Repo docs stay clean.AGENTS.md, CLAUDE.md, and docs remain stable policy; threadnote carries living context.
  • Team context is explicit. Publish only curated durable memories to a team git repo; personal handoffs stay local.
Why not just Markdown files?
Use Markdown files. threadnote makes them operational.
  • AGENTS.md / CLAUDE.md / repo docs: stable, reviewed, version-controlled rules.
  • Random notes: easy to write, hard for agents to rank, scope, update, or know when stale.
  • threadnote memories: Markdown on disk plus semantic recall, stable URIs, lifecycle (durable, handoff, archived), scoped compaction, MCP tools, and safe team sharing.
The source of truth is still local files. The benefit is that agents know how to find the right file, decide whether it is current, update it without creating duplicates, and hand it to the next agent.
By default, OpenViking builds the semantic index locally with a GGUF embedding model through llama.cpp, so the memory
corpus does not need to be sent to a hosted embedding service for recall.
Agent perspective
These are workflow examples from an agent's point of view, not external endorsements.
Codex before threadnote: "I inspect the repo, ask what changed, rediscover the test command, and hope the compacted chat summary did not drop the important caveat."
Codex with threadnote: "I recall the branch handoff and durable feature memory first. I can name the files touched, the last failing check, the design decision behind the code, and the next step before editing."
Claude Code before threadnote: "A long debugging thread compacts into a vague narrative. The next turn knows the arc, but not the exact command, blocker, or decision."
Claude Code with threadnote: "The pre-compact handoff captures the concrete state. The next session reads the same memory and continues without asking the user to reconstruct it."
Cross-repo work with threadnote: "I recall the mobile_web workset once and see the relevant handoffs, seeded guidance, and dependency facts for both apps before changing either one."
Quickstart
curl -fsSL https://raw.githubusercontent.com/Kashkovsky/threadnote/main/scripts/install.sh | sh
threadnote mcp-install claude --apply # or codex / cursor / copilot
threadnote doctor --dry-run
The default MCP registration exposes six common tools; the CLI remains available for every advanced workflow. Open a fresh agent session after installing MCP so the new server registration loads.
Explore the wiki
  • Installation — the one-line installer, manual install, runtime overrides, and updates.
  • Configuration — environment variables, THREADNOTE_HOME, host/port, and the seed manifest.
  • Architecture — how the stdio MCP adapter, openviking-server, the viking:// URI scheme, and on-disk storage fit together.
  • Threadnote vs Native AI Memory — why portable team memory is different from ChatGPT, Gemini, and Claude memory.
  • Memory Lifecycle — durable vs handoff, active vs archived, project/topic paths, and compaction.
  • Recall and Read — searching context, reading and listing viking:// URIs, and scope inference.
  • Seeding Repos and Skills — curated manifest seeding for repo guidance, worksets, dependency facts, docs, and SKILL.md catalogs.
  • Sharing Memories — publishing curated durable memories to a team git repo and syncing teammates' updates.
  • Safety and Security — local-by-default writes, ignore rules, redaction, secret scanning, and explicit config changes.
  • CLI Reference — every threadnote command and its flags.
  • Web Manager — the local web UI (threadnote manage) for browsing, editing, and managing memories.
  • Agent Instructions — the user-level guidance installed for Codex, Claude, Cursor, and Copilot, plus Claude Code hooks.
  • Migration — moving an existing repo workflow onto threadnote and migrating legacy memories.
  • Troubleshooting — diagnosing install, health, MCP, and server problems.
  • Concepts and FAQ — core terms and common questions.
Links
License: AGPL-3.0-or-later. Built on OpenViking 0.3.24. Requires Node.js >= 20.
See also: Installation, Architecture, Concepts and FAQ.
GitHub · npm · walkthrough deck · OpenViking · AGPL-3.0-or-later
threadnote
Start here
Concepts
Workflows
Reference
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Home
Jump to bottom

Denys Kashkovskyi edited this page Jul 23, 2026
·
7 revisions
Home
Threadnote lets one engineer's coding agent publish a durable project decision that another engineer's different agent
can recall. Alice can capture an API contract with Codex; Bob can auto-sync and read it from Claude Code, Cursor, or
Copilot during the next task.
That cross-user, cross-agent path is the product's main value. Persistent personal memory is the foundation, not the
destination.
Alice + Codex ──publish curated memory──▶ team Git repo
│
auto-sync on recall
▼
Bob + Claude Code / Cursor / Copilot

Personal handoffs, preferences, incidents, and unpublished memories stay local. Only curated durable knowledge or
reusable artifacts that a user explicitly publishes enter the team Git repo, after preview and secret scanning.
What breaks without it
  • Useful discoveries stay trapped in one person's chat or one vendor's project.
  • Each coding agent has its own context. Switching users or vendors means starting over.
  • Persistence alone creates better private silos; it does not make project knowledge portable to a teammate's agent.
  • Markdown notes are passive. The agent still has to know which note matters now, whether it is stale, and where to write the next handoff.
  • CLAUDE.md / AGENTS.md is per-repo and static. It cannot carry an in-flight feature's design decisions across sessions, much less across agents or repos.
  • Team knowledge stays in DMs. A decision made in a Slack thread never reaches a teammate's agent.
Different from native AI memory
ChatGPT, Gemini, and Claude provide useful continuity inside their own products. ChatGPT and Claude support shared
projects; Gemini can share Gems and chats. Threadnote solves a different boundary: a team can keep explicit engineering
knowledge in Markdown and Git, then let each developer use it from a supported coding agent without standardizing on
one AI vendor.
ThreadnoteNative memory / vendor collaboration spaces
ReachAcross users, machines, and supported coding-agent vendorsInside the provider's account, app, shared project, or Gem
Team source of truthUser-controlled Markdown and GitProvider-hosted chats, files, memory, and settings
Knowledge unitExplicit durable/handoff/archive record with a stable URIProvider-managed memory, project, Gem, or conversation
Recall pathLocal semantic index returns URI candidates; agents read selected recordsProvider-managed retrieval and search
Sharing boundaryPublish selected durable knowledge; personal working state localMembership, links, and controls within the provider
Best fitEngineering teams using multiple agents in real repositoriesContinuity and collaboration inside one AI product
See Threadnote vs Native AI Memory for a product-by-product comparison and links to the official documentation.
What you get
  • One engineer's learning reaches every teammate's agent. Shared memories auto-sync before normal recall/read calls.
  • The team does not have to choose one agent vendor. Codex, Claude Code, Cursor, and Copilot use one MCP workflow.
  • Sharing is explicit and reviewable. Preview, scrub, commit, and push only selected durable memories or artifacts.
  • Private working state stays private. Personal handoffs and unpublished context remain on the local machine.
  • Recall is local and context-efficient. A local embedding model ranks semantic matches, then the agent reads only
the selected viking:// records instead of replaying the full memory history.
  • Fresh agents start with recall, not amnesia. A new session can read the latest handoff before touching code.
  • Compaction becomes a checkpoint, not memory loss. Durable facts and current status survive the summary.
  • Agent switching stops resetting the task. Codex can leave a handoff that Claude Code, Cursor, or Copilot can read.
  • Cross-repo work stops scattering context. Worksets let you recall related repos together, such as a mobile app, web app, and shared library.
  • Handoffs can carry review state. PR, issue, CI, blockers, next steps, and referenced memories stay attached to the current work log.
  • Repo docs stay clean.AGENTS.md, CLAUDE.md, and docs remain stable policy; threadnote carries living context.
  • Team context is explicit. Publish only curated durable memories to a team git repo; personal handoffs stay local.
Why not just Markdown files?
Use Markdown files. threadnote makes them operational.
  • AGENTS.md / CLAUDE.md / repo docs: stable, reviewed, version-controlled rules.
  • Random notes: easy to write, hard for agents to rank, scope, update, or know when stale.
  • threadnote memories: Markdown on disk plus semantic recall, stable URIs, lifecycle (durable, handoff, archived), scoped compaction, MCP tools, and safe team sharing.
The source of truth is still local files. The benefit is that agents know how to find the right file, decide whether it is current, update it without creating duplicates, and hand it to the next agent.
By default, OpenViking builds the semantic index locally with a GGUF embedding model through llama.cpp, so the memory
corpus does not need to be sent to a hosted embedding service for recall.
Agent perspective
These are workflow examples from an agent's point of view, not external endorsements.
Codex before threadnote: "I inspect the repo, ask what changed, rediscover the test command, and hope the compacted chat summary did not drop the important caveat."
Codex with threadnote: "I recall the branch handoff and durable feature memory first. I can name the files touched, the last failing check, the design decision behind the code, and the next step before editing."
Claude Code before threadnote: "A long debugging thread compacts into a vague narrative. The next turn knows the arc, but not the exact command, blocker, or decision."
Claude Code with threadnote: "The pre-compact handoff captures the concrete state. The next session reads the same memory and continues without asking the user to reconstruct it."
Cross-repo work with threadnote: "I recall the mobile_web workset once and see the relevant handoffs, seeded guidance, and dependency facts for both apps before changing either one."
Quickstart
curl -fsSL https://raw.githubusercontent.com/Kashkovsky/threadnote/main/scripts/install.sh | sh
threadnote mcp-install claude --apply # or codex / cursor / copilot
threadnote doctor --dry-run
The default MCP registration exposes six common tools; the CLI remains available for every advanced workflow. Open a fresh agent session after installing MCP so the new server registration loads.
Explore the wiki
  • Installation — the one-line installer, manual install, runtime overrides, and updates.
  • Configuration — environment variables, THREADNOTE_HOME, host/port, and the seed manifest.
  • Architecture — how the stdio MCP adapter, openviking-server, the viking:// URI scheme, and on-disk storage fit together.
  • Threadnote vs Native AI Memory — why portable team memory is different from ChatGPT, Gemini, and Claude memory.
  • Memory Lifecycle — durable vs handoff, active vs archived, project/topic paths, and compaction.
  • Recall and Read — searching context, reading and listing viking:// URIs, and scope inference.
  • Seeding Repos and Skills — curated manifest seeding for repo guidance, worksets, dependency facts, docs, and SKILL.md catalogs.
  • Sharing Memories — publishing curated durable memories to a team git repo and syncing teammates' updates.
  • Safety and Security — local-by-default writes, ignore rules, redaction, secret scanning, and explicit config changes.
  • CLI Reference — every threadnote command and its flags.
  • Web Manager — the local web UI (threadnote manage) for browsing, editing, and managing memories.
  • Agent Instructions — the user-level guidance installed for Codex, Claude, Cursor, and Copilot, plus Claude Code hooks.
  • Migration — moving an existing repo workflow onto threadnote and migrating legacy memories.
  • Troubleshooting — diagnosing install, health, MCP, and server problems.
  • Concepts and FAQ — core terms and common questions.
Links
License: AGPL-3.0-or-later. Built on OpenViking 0.3.24. Requires Node.js >= 20.
See also: Installation, Architecture, Concepts and FAQ.
GitHub · npm · walkthrough deck · OpenViking · AGPL-3.0-or-later
threadnote
Start here
Concepts
Workflows
Reference
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Home
Jump to bottom

Denys Kashkovskyi edited this page Jul 23, 2026
·
7 revisions
Home
Threadnote lets one engineer's coding agent publish a durable project decision that another engineer's different agent
can recall. Alice can capture an API contract with Codex; Bob can auto-sync and read it from Claude Code, Cursor, or
Copilot during the next task.
That cross-user, cross-agent path is the product's main value. Persistent personal memory is the foundation, not the
destination.
Alice + Codex ──publish curated memory──▶ team Git repo
│
auto-sync on recall
▼
Bob + Claude Code / Cursor / Copilot

Personal handoffs, preferences, incidents, and unpublished memories stay local. Only curated durable knowledge or
reusable artifacts that a user explicitly publishes enter the team Git repo, after preview and secret scanning.
What breaks without it
  • Useful discoveries stay trapped in one person's chat or one vendor's project.
  • Each coding agent has its own context. Switching users or vendors means starting over.
  • Persistence alone creates better private silos; it does not make project knowledge portable to a teammate's agent.
  • Markdown notes are passive. The agent still has to know which note matters now, whether it is stale, and where to write the next handoff.
  • CLAUDE.md / AGENTS.md is per-repo and static. It cannot carry an in-flight feature's design decisions across sessions, much less across agents or repos.
  • Team knowledge stays in DMs. A decision made in a Slack thread never reaches a teammate's agent.
Different from native AI memory
ChatGPT, Gemini, and Claude provide useful continuity inside their own products. ChatGPT and Claude support shared
projects; Gemini can share Gems and chats. Threadnote solves a different boundary: a team can keep explicit engineering
knowledge in Markdown and Git, then let each developer use it from a supported coding agent without standardizing on
one AI vendor.
ThreadnoteNative memory / vendor collaboration spaces
ReachAcross users, machines, and supported coding-agent vendorsInside the provider's account, app, shared project, or Gem
Team source of truthUser-controlled Markdown and GitProvider-hosted chats, files, memory, and settings
Knowledge unitExplicit durable/handoff/archive record with a stable URIProvider-managed memory, project, Gem, or conversation
Recall pathLocal semantic index returns URI candidates; agents read selected recordsProvider-managed retrieval and search
Sharing boundaryPublish selected durable knowledge; personal working state localMembership, links, and controls within the provider
Best fitEngineering teams using multiple agents in real repositoriesContinuity and collaboration inside one AI product
See Threadnote vs Native AI Memory for a product-by-product comparison and links to the official documentation.
What you get
  • One engineer's learning reaches every teammate's agent. Shared memories auto-sync before normal recall/read calls.
  • The team does not have to choose one agent vendor. Codex, Claude Code, Cursor, and Copilot use one MCP workflow.
  • Sharing is explicit and reviewable. Preview, scrub, commit, and push only selected durable memories or artifacts.
  • Private working state stays private. Personal handoffs and unpublished context remain on the local machine.
  • Recall is local and context-efficient. A local embedding model ranks semantic matches, then the agent reads only
the selected viking:// records instead of replaying the full memory history.
  • Fresh agents start with recall, not amnesia. A new session can read the latest handoff before touching code.
  • Compaction becomes a checkpoint, not memory loss. Durable facts and current status survive the summary.
  • Agent switching stops resetting the task. Codex can leave a handoff that Claude Code, Cursor, or Copilot can read.
  • Cross-repo work stops scattering context. Worksets let you recall related repos together, such as a mobile app, web app, and shared library.
  • Handoffs can carry review state. PR, issue, CI, blockers, next steps, and referenced memories stay attached to the current work log.
  • Repo docs stay clean.AGENTS.md, CLAUDE.md, and docs remain stable policy; threadnote carries living context.
  • Team context is explicit. Publish only curated durable memories to a team git repo; personal handoffs stay local.
Why not just Markdown files?
Use Markdown files. threadnote makes them operational.
  • AGENTS.md / CLAUDE.md / repo docs: stable, reviewed, version-controlled rules.
  • Random notes: easy to write, hard for agents to rank, scope, update, or know when stale.
  • threadnote memories: Markdown on disk plus semantic recall, stable URIs, lifecycle (durable, handoff, archived), scoped compaction, MCP tools, and safe team sharing.
The source of truth is still local files. The benefit is that agents know how to find the right file, decide whether it is current, update it without creating duplicates, and hand it to the next agent.
By default, OpenViking builds the semantic index locally with a GGUF embedding model through llama.cpp, so the memory
corpus does not need to be sent to a hosted embedding service for recall.
Agent perspective
These are workflow examples from an agent's point of view, not external endorsements.
Codex before threadnote: "I inspect the repo, ask what changed, rediscover the test command, and hope the compacted chat summary did not drop the important caveat."
Codex with threadnote: "I recall the branch handoff and durable feature memory first. I can name the files touched, the last failing check, the design decision behind the code, and the next step before editing."
Claude Code before threadnote: "A long debugging thread compacts into a vague narrative. The next turn knows the arc, but not the exact command, blocker, or decision."
Claude Code with threadnote: "The pre-compact handoff captures the concrete state. The next session reads the same memory and continues without asking the user to reconstruct it."
Cross-repo work with threadnote: "I recall the mobile_web workset once and see the relevant handoffs, seeded guidance, and dependency facts for both apps before changing either one."
Quickstart
curl -fsSL https://raw.githubusercontent.com/Kashkovsky/threadnote/main/scripts/install.sh | sh
threadnote mcp-install claude --apply # or codex / cursor / copilot
threadnote doctor --dry-run
The default MCP registration exposes six common tools; the CLI remains available for every advanced workflow. Open a fresh agent session after installing MCP so the new server registration loads.
Explore the wiki
  • Installation — the one-line installer, manual install, runtime overrides, and updates.
  • Configuration — environment variables, THREADNOTE_HOME, host/port, and the seed manifest.
  • Architecture — how the stdio MCP adapter, openviking-server, the viking:// URI scheme, and on-disk storage fit together.
  • Threadnote vs Native AI Memory — why portable team memory is different from ChatGPT, Gemini, and Claude memory.
  • Memory Lifecycle — durable vs handoff, active vs archived, project/topic paths, and compaction.
  • Recall and Read — searching context, reading and listing viking:// URIs, and scope inference.
  • Seeding Repos and Skills — curated manifest seeding for repo guidance, worksets, dependency facts, docs, and SKILL.md catalogs.
  • Sharing Memories — publishing curated durable memories to a team git repo and syncing teammates' updates.
  • Safety and Security — local-by-default writes, ignore rules, redaction, secret scanning, and explicit config changes.
  • CLI Reference — every threadnote command and its flags.
  • Web Manager — the local web UI (threadnote manage) for browsing, editing, and managing memories.
  • Agent Instructions — the user-level guidance installed for Codex, Claude, Cursor, and Copilot, plus Claude Code hooks.
  • Migration — moving an existing repo workflow onto threadnote and migrating legacy memories.
  • Troubleshooting — diagnosing install, health, MCP, and server problems.
  • Concepts and FAQ — core terms and common questions.
Links
License: AGPL-3.0-or-later. Built on OpenViking 0.3.24. Requires Node.js >= 20.
See also: Installation, Architecture, Concepts and FAQ.
GitHub · npm · walkthrough deck · OpenViking · AGPL-3.0-or-later
threadnote
Start here
Concepts
Workflows
Reference
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Home
Jump to bottom

Denys Kashkovskyi edited this page Jul 23, 2026
·
7 revisions
Home
Threadnote lets one engineer's coding agent publish a durable project decision that another engineer's different agent
can recall. Alice can capture an API contract with Codex; Bob can auto-sync and read it from Claude Code, Cursor, or
Copilot during the next task.
That cross-user, cross-agent path is the product's main value. Persistent personal memory is the foundation, not the
destination.
Alice + Codex ──publish curated memory──▶ team Git repo
│
auto-sync on recall
▼
Bob + Claude Code / Cursor / Copilot

Personal handoffs, preferences, incidents, and unpublished memories stay local. Only curated durable knowledge or
reusable artifacts that a user explicitly publishes enter the team Git repo, after preview and secret scanning.
What breaks without it
  • Useful discoveries stay trapped in one person's chat or one vendor's project.
  • Each coding agent has its own context. Switching users or vendors means starting over.
  • Persistence alone creates better private silos; it does not make project knowledge portable to a teammate's agent.
  • Markdown notes are passive. The agent still has to know which note matters now, whether it is stale, and where to write the next handoff.
  • CLAUDE.md / AGENTS.md is per-repo and static. It cannot carry an in-flight feature's design decisions across sessions, much less across agents or repos.
  • Team knowledge stays in DMs. A decision made in a Slack thread never reaches a teammate's agent.
Different from native AI memory
ChatGPT, Gemini, and Claude provide useful continuity inside their own products. ChatGPT and Claude support shared
projects; Gemini can share Gems and chats. Threadnote solves a different boundary: a team can keep explicit engineering
knowledge in Markdown and Git, then let each developer use it from a supported coding agent without standardizing on
one AI vendor.
ThreadnoteNative memory / vendor collaboration spaces
ReachAcross users, machines, and supported coding-agent vendorsInside the provider's account, app, shared project, or Gem
Team source of truthUser-controlled Markdown and GitProvider-hosted chats, files, memory, and settings
Knowledge unitExplicit durable/handoff/archive record with a stable URIProvider-managed memory, project, Gem, or conversation
Recall pathLocal semantic index returns URI candidates; agents read selected recordsProvider-managed retrieval and search
Sharing boundaryPublish selected durable knowledge; personal working state localMembership, links, and controls within the provider
Best fitEngineering teams using multiple agents in real repositoriesContinuity and collaboration inside one AI product
See Threadnote vs Native AI Memory for a product-by-product comparison and links to the official documentation.
What you get
  • One engineer's learning reaches every teammate's agent. Shared memories auto-sync before normal recall/read calls.
  • The team does not have to choose one agent vendor. Codex, Claude Code, Cursor, and Copilot use one MCP workflow.
  • Sharing is explicit and reviewable. Preview, scrub, commit, and push only selected durable memories or artifacts.
  • Private working state stays private. Personal handoffs and unpublished context remain on the local machine.
  • Recall is local and context-efficient. A local embedding model ranks semantic matches, then the agent reads only
the selected viking:// records instead of replaying the full memory history.
  • Fresh agents start with recall, not amnesia. A new session can read the latest handoff before touching code.
  • Compaction becomes a checkpoint, not memory loss. Durable facts and current status survive the summary.
  • Agent switching stops resetting the task. Codex can leave a handoff that Claude Code, Cursor, or Copilot can read.
  • Cross-repo work stops scattering context. Worksets let you recall related repos together, such as a mobile app, web app, and shared library.
  • Handoffs can carry review state. PR, issue, CI, blockers, next steps, and referenced memories stay attached to the current work log.
  • Repo docs stay clean.AGENTS.md, CLAUDE.md, and docs remain stable policy; threadnote carries living context.
  • Team context is explicit. Publish only curated durable memories to a team git repo; personal handoffs stay local.
Why not just Markdown files?
Use Markdown files. threadnote makes them operational.
  • AGENTS.md / CLAUDE.md / repo docs: stable, reviewed, version-controlled rules.
  • Random notes: easy to write, hard for agents to rank, scope, update, or know when stale.
  • threadnote memories: Markdown on disk plus semantic recall, stable URIs, lifecycle (durable, handoff, archived), scoped compaction, MCP tools, and safe team sharing.
The source of truth is still local files. The benefit is that agents know how to find the right file, decide whether it is current, update it without creating duplicates, and hand it to the next agent.
By default, OpenViking builds the semantic index locally with a GGUF embedding model through llama.cpp, so the memory
corpus does not need to be sent to a hosted embedding service for recall.
Agent perspective
These are workflow examples from an agent's point of view, not external endorsements.
Codex before threadnote: "I inspect the repo, ask what changed, rediscover the test command, and hope the compacted chat summary did not drop the important caveat."
Codex with threadnote: "I recall the branch handoff and durable feature memory first. I can name the files touched, the last failing check, the design decision behind the code, and the next step before editing."
Claude Code before threadnote: "A long debugging thread compacts into a vague narrative. The next turn knows the arc, but not the exact command, blocker, or decision."
Claude Code with threadnote: "The pre-compact handoff captures the concrete state. The next session reads the same memory and continues without asking the user to reconstruct it."
Cross-repo work with threadnote: "I recall the mobile_web workset once and see the relevant handoffs, seeded guidance, and dependency facts for both apps before changing either one."
Quickstart
curl -fsSL https://raw.githubusercontent.com/Kashkovsky/threadnote/main/scripts/install.sh | sh
threadnote mcp-install claude --apply # or codex / cursor / copilot
threadnote doctor --dry-run
The default MCP registration exposes six common tools; the CLI remains available for every advanced workflow. Open a fresh agent session after installing MCP so the new server registration loads.
Explore the wiki
  • Installation — the one-line installer, manual install, runtime overrides, and updates.
  • Configuration — environment variables, THREADNOTE_HOME, host/port, and the seed manifest.
  • Architecture — how the stdio MCP adapter, openviking-server, the viking:// URI scheme, and on-disk storage fit together.
  • Threadnote vs Native AI Memory — why portable team memory is different from ChatGPT, Gemini, and Claude memory.
  • Memory Lifecycle — durable vs handoff, active vs archived, project/topic paths, and compaction.
  • Recall and Read — searching context, reading and listing viking:// URIs, and scope inference.
  • Seeding Repos and Skills — curated manifest seeding for repo guidance, worksets, dependency facts, docs, and SKILL.md catalogs.
  • Sharing Memories — publishing curated durable memories to a team git repo and syncing teammates' updates.
  • Safety and Security — local-by-default writes, ignore rules, redaction, secret scanning, and explicit config changes.
  • CLI Reference — every threadnote command and its flags.
  • Web Manager — the local web UI (threadnote manage) for browsing, editing, and managing memories.
  • Agent Instructions — the user-level guidance installed for Codex, Claude, Cursor, and Copilot, plus Claude Code hooks.
  • Migration — moving an existing repo workflow onto threadnote and migrating legacy memories.
  • Troubleshooting — diagnosing install, health, MCP, and server problems.
  • Concepts and FAQ — core terms and common questions.
Links
License: AGPL-3.0-or-later. Built on OpenViking 0.3.24. Requires Node.js >= 20.
See also: Installation, Architecture, Concepts and FAQ.
GitHub · npm · walkthrough deck · OpenViking · AGPL-3.0-or-later
threadnote
Start here
Concepts
Workflows
Reference
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Home
Jump to bottom

Denys Kashkovskyi edited this page Jul 23, 2026
·
7 revisions
Home
Threadnote lets one engineer's coding agent publish a durable project decision that another engineer's different agent
can recall. Alice can capture an API contract with Codex; Bob can auto-sync and read it from Claude Code, Cursor, or
Copilot during the next task.
That cross-user, cross-agent path is the product's main value. Persistent personal memory is the foundation, not the
destination.
Alice + Codex ──publish curated memory──▶ team Git repo
│
auto-sync on recall
▼
Bob + Claude Code / Cursor / Copilot

Personal handoffs, preferences, incidents, and unpublished memories stay local. Only curated durable knowledge or
reusable artifacts that a user explicitly publishes enter the team Git repo, after preview and secret scanning.
What breaks without it
  • Useful discoveries stay trapped in one person's chat or one vendor's project.
  • Each coding agent has its own context. Switching users or vendors means starting over.
  • Persistence alone creates better private silos; it does not make project knowledge portable to a teammate's agent.
  • Markdown notes are passive. The agent still has to know which note matters now, whether it is stale, and where to write the next handoff.
  • CLAUDE.md / AGENTS.md is per-repo and static. It cannot carry an in-flight feature's design decisions across sessions, much less across agents or repos.
  • Team knowledge stays in DMs. A decision made in a Slack thread never reaches a teammate's agent.
Different from native AI memory
ChatGPT, Gemini, and Claude provide useful continuity inside their own products. ChatGPT and Claude support shared
projects; Gemini can share Gems and chats. Threadnote solves a different boundary: a team can keep explicit engineering
knowledge in Markdown and Git, then let each developer use it from a supported coding agent without standardizing on
one AI vendor.
ThreadnoteNative memory / vendor collaboration spaces
ReachAcross users, machines, and supported coding-agent vendorsInside the provider's account, app, shared project, or Gem
Team source of truthUser-controlled Markdown and GitProvider-hosted chats, files, memory, and settings
Knowledge unitExplicit durable/handoff/archive record with a stable URIProvider-managed memory, project, Gem, or conversation
Recall pathLocal semantic index returns URI candidates; agents read selected recordsProvider-managed retrieval and search
Sharing boundaryPublish selected durable knowledge; personal working state localMembership, links, and controls within the provider
Best fitEngineering teams using multiple agents in real repositoriesContinuity and collaboration inside one AI product
See Threadnote vs Native AI Memory for a product-by-product comparison and links to the official documentation.
What you get
  • One engineer's learning reaches every teammate's agent. Shared memories auto-sync before normal recall/read calls.
  • The team does not have to choose one agent vendor. Codex, Claude Code, Cursor, and Copilot use one MCP workflow.
  • Sharing is explicit and reviewable. Preview, scrub, commit, and push only selected durable memories or artifacts.
  • Private working state stays private. Personal handoffs and unpublished context remain on the local machine.
  • Recall is local and context-efficient. A local embedding model ranks semantic matches, then the agent reads only
the selected viking:// records instead of replaying the full memory history.
  • Fresh agents start with recall, not amnesia. A new session can read the latest handoff before touching code.
  • Compaction becomes a checkpoint, not memory loss. Durable facts and current status survive the summary.
  • Agent switching stops resetting the task. Codex can leave a handoff that Claude Code, Cursor, or Copilot can read.
  • Cross-repo work stops scattering context. Worksets let you recall related repos together, such as a mobile app, web app, and shared library.
  • Handoffs can carry review state. PR, issue, CI, blockers, next steps, and referenced memories stay attached to the current work log.
  • Repo docs stay clean.AGENTS.md, CLAUDE.md, and docs remain stable policy; threadnote carries living context.
  • Team context is explicit. Publish only curated durable memories to a team git repo; personal handoffs stay local.
Why not just Markdown files?
Use Markdown files. threadnote makes them operational.
  • AGENTS.md / CLAUDE.md / repo docs: stable, reviewed, version-controlled rules.
  • Random notes: easy to write, hard for agents to rank, scope, update, or know when stale.
  • threadnote memories: Markdown on disk plus semantic recall, stable URIs, lifecycle (durable, handoff, archived), scoped compaction, MCP tools, and safe team sharing.
The source of truth is still local files. The benefit is that agents know how to find the right file, decide whether it is current, update it without creating duplicates, and hand it to the next agent.
By default, OpenViking builds the semantic index locally with a GGUF embedding model through llama.cpp, so the memory
corpus does not need to be sent to a hosted embedding service for recall.
Agent perspective
These are workflow examples from an agent's point of view, not external endorsements.
Codex before threadnote: "I inspect the repo, ask what changed, rediscover the test command, and hope the compacted chat summary did not drop the important caveat."
Codex with threadnote: "I recall the branch handoff and durable feature memory first. I can name the files touched, the last failing check, the design decision behind the code, and the next step before editing."
Claude Code before threadnote: "A long debugging thread compacts into a vague narrative. The next turn knows the arc, but not the exact command, blocker, or decision."
Claude Code with threadnote: "The pre-compact handoff captures the concrete state. The next session reads the same memory and continues without asking the user to reconstruct it."
Cross-repo work with threadnote: "I recall the mobile_web workset once and see the relevant handoffs, seeded guidance, and dependency facts for both apps before changing either one."
Quickstart
curl -fsSL https://raw.githubusercontent.com/Kashkovsky/threadnote/main/scripts/install.sh | sh
threadnote mcp-install claude --apply # or codex / cursor / copilot
threadnote doctor --dry-run
The default MCP registration exposes six common tools; the CLI remains available for every advanced workflow. Open a fresh agent session after installing MCP so the new server registration loads.
Explore the wiki
  • Installation — the one-line installer, manual install, runtime overrides, and updates.
  • Configuration — environment variables, THREADNOTE_HOME, host/port, and the seed manifest.
  • Architecture — how the stdio MCP adapter, openviking-server, the viking:// URI scheme, and on-disk storage fit together.
  • Threadnote vs Native AI Memory — why portable team memory is different from ChatGPT, Gemini, and Claude memory.
  • Memory Lifecycle — durable vs handoff, active vs archived, project/topic paths, and compaction.
  • Recall and Read — searching context, reading and listing viking:// URIs, and scope inference.
  • Seeding Repos and Skills — curated manifest seeding for repo guidance, worksets, dependency facts, docs, and SKILL.md catalogs.
  • Sharing Memories — publishing curated durable memories to a team git repo and syncing teammates' updates.
  • Safety and Security — local-by-default writes, ignore rules, redaction, secret scanning, and explicit config changes.
  • CLI Reference — every threadnote command and its flags.
  • Web Manager — the local web UI (threadnote manage) for browsing, editing, and managing memories.
  • Agent Instructions — the user-level guidance installed for Codex, Claude, Cursor, and Copilot, plus Claude Code hooks.
  • Migration — moving an existing repo workflow onto threadnote and migrating legacy memories.
  • Troubleshooting — diagnosing install, health, MCP, and server problems.
  • Concepts and FAQ — core terms and common questions.
Links
License: AGPL-3.0-or-later. Built on OpenViking 0.3.24. Requires Node.js >= 20.
See also: Installation, Architecture, Concepts and FAQ.
GitHub · npm · walkthrough deck · OpenViking · AGPL-3.0-or-later
threadnote
Start here
Concepts
Workflows
Reference
Clone this wiki locally