KIOKU v0.6.0: multi-agent support — same vault across Claude / Codex / OpenCode / Gemini CLI
megaphone
·
2026-04-24
·
via DEV Community
<h2> Context </h2> <p>I've been building <a href="https://github.com/megaphone-tokyo/kioku" rel="noopener noreferrer">KIOKU</a> — a memory / second-brain OSS for Claude Code and Claude Desktop. The <a href="https://dev.to/megaphone/kioku-v050-v051-unified-ingest-router-hot-cache-shipped-same-day-1fdd">previous post</a> covered v0.5.0 + v0.5.1, the "ingest → persist" pair: unified document ingestion and a hot cache that survives Claude Code's compaction.</p> <p><strong>v0.6.0</strong> (shipped today, 2026-04-24) is a different shape of release. Where v0.5 closed the loop on "what KIOKU does internally," v0.6 is about <strong>opening KIOKU up externally</strong>. The headline change:</p> <blockquote> <p><strong>KIOKU is no longer Claude-only.</strong> The same skills now run on Codex CLI, OpenCode, and Gemini CLI, with a shared Obsidian vault acting as second brain across all four agents.</p> </blockquote> <p>Alongside that, v0.6 ships four more changes:</p> <ul> <li>🔀 <strong>Multi-agent support (the main story)</strong> — Claude Code / Codex CLI / OpenCode / Gemini CLI all share the same vault</li> <li>📦 <strong>Claude Code plugin marketplace</strong> — one-command install</li> <li>📊 <strong>Obsidian Bases dashboard</strong> — 9 live views over your wiki (first real UI surface)</li> <li>🔁 <strong>Raw Markdown delta tracking</strong> — sha256-gated so unchanged files stop costing you LLM calls</li> <li>🛡 <strong>Formal security policy</strong> — CVE classification, Safe Harbor, 90-day coordinated disclosure</li> </ul> <p>Each of those corresponds to "another group of people who can now engage with KIOKU": non-Claude agent users, plugin discoverers, Obsidian power users, people worried about runaway API bills, and security researchers.</p> <p><a href="https://github.com/megaphone-tokyo/kioku" rel="noopener noreferrer">https://github.com/megaphone-tokyo/kioku</a></p> <h2> 1. Multi-agent: same vault, any agent </h2> <p>This is the biggest directional change in v0.6 and the one I want to spend the most words on.</p> <h3> Before / After </h3> <p><strong>Before (v0.5):</strong><br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>[Claude Code] → KIOKU skills → MCP → Vault (second brain) [Codex CLI / OpenCode / Gemini CLI] → ❌ (skills don't install there) </code></pre> </div> <p>The vault itself was always Markdown files on disk, so other agents could technically read them. But KIOKU's "automatically grow, search, structure" layer was wired to Claude Code only.</p> <p><strong>After (v0.6):</strong><br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code> ┌── Claude Code ──┐ ├── Codex CLI ────┤ [you] ─────→ ┤ ├──→ KIOKU skills → Vault (shared file-level) ├── OpenCode ─────┤ └── Gemini CLI ───┘ </code></pre> </div> <p>The same skill payload serves all four agents, and the Obsidian vault is a shared set of Markdown files. One vault, one accumulated set of notes, multiple agents reading and writing to it.</p> <blockquote> <p><strong>Scope note</strong>: The MCP server stays agent-agnostic, but per-agent config setup docs are landing in v0.7. Automatic session logging and hot-cache injection remain Claude Code-specific in v0.6 (Gemini/Codex hook port is planned for v0.7).</p> </blockquote> <h3> Setup </h3> <p>One script:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>bash scripts/setup-multi-agent.sh <span class="c"># symlinks the skills into:</span> <span class="c"># ~/.codex/skills/kioku/</span> <span class="c"># ~/.opencode/skills/kioku/</span> <span class="c"># ~/.gemini/skills/kioku/</span> </code></pre> </div> <p>Rerun anytime — it's idempotent and the test suite pins that.</p> <h3> Why this was technically possible </h3> <p>Honestly, <strong>there was no longer a good reason to keep KIOKU Claude-only</strong>. The skill layer — the set of instructions that teach an agent how to manage a Karpathy-style Wiki — had always been <strong>just Markdown + frontmatter</strong>. We had <code>maxTurns</code> and a few other Claude Code-specific fields, but they weren't load-bearing.</p> <p>The core extractor is Node stdlib + Bash. The MCP server depends only on <code>@modelcontextprotocol/sdk</code> and speaks stdio — no agent lock-in below the skill layer either. So v0.6 is less "we rewrote KIOKU for portability" and more "we formalized and documented the portability that was already latent in the codebase."</p> <h3> Three use cases this unlocks </h3> <p><strong>(1) Agent lock-in avoidance.</strong> If you're a developer who cares about not getting vendor-locked, KIOKU's vault is agent-independent Markdown on disk. You can move between Claude / Codex / Gemini and the accumulated knowledge follows.</p> <p><strong>(2) Cross-agent workflows.</strong> You might main on Claude Code but occasionally reach for Codex (OpenAI's latest on a specific task) or Gemini (long-context for a specific file). Before v0.6, switching agents meant losing KIOKU skill access entirely. Now the skill layer and the vault itself are shared across agents, while the automatic-memory layer (session logs + hot cache injection) remains Claude Code-specific (Gemini/Codex parity planned for v0.7).</p> <p><strong>(3) Comparative evaluation.</strong> If you're a researcher or prompt engineer comparing agents on the same task, v0.6 lets you run Claude, Codex, and Gemini against the same accumulated context rather than three separate siloed contexts.</p> <h3> What I explicitly didn't do </h3> <p>I didn't fork KIOKU into four agent-specific variants. That path leads to 4× the maintenance, bugs that diverge, and version drift across the variants. The v0.6 approach is <strong>one skill definition, symlinked into four locations</strong>. A fifth or sixth agent in the future means adding a symlink target, not a fork.</p> <h3> Personal dogfooding note </h3> <p>I primarily use Claude Code, but I reach for Codex and Gemini on specific tasks (cross-checking a long output, running the same prompt against two models to compare). Before v0.6, this meant my vault was fed only by Claude work, and the agent-switching had a "fresh session" feeling every time. With multi-agent enabled, my vault is now shared across agents at the file level. The hot-cache-driven context and automatic session logs still live in Claude Code only; v0.7 will bring hook-level parity.</p> <h2> 2. Plugin marketplace: the install surface </h2> <p>Before v0.6, installing KIOKU meant downloading an <code>.mcpb</code> bundle from GitHub Releases and drag-dropping it into Claude Desktop. That's a reasonable flow for someone who'd already committed to using the tool, but it's a high-friction first contact for a prospective user who just heard about it on HN or in a Slack.</p> <p>v0.6 registers KIOKU in the Claude Code plugin marketplace:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>claude marketplace add megaphone-tokyo/kioku claude plugin <span class="nb">install </span>kioku@megaphone-tokyo </code></pre> </div> <p>The <code>.mcpb</code> path stays — it's kept for Claude Desktop-first users who don't touch the Code CLI. But the default discovery path is now the same as any other Claude Code plugin. That's less "cool bespoke install" and more "boring standard install," which is the right trade for reducing friction.</p> <h2> 3. Obsidian Bases dashboard: the first real UI surface </h2> <p>Up to v0.5, KIOKU's UX was "quietly grow a wiki in the background, and eventually open Obsidian to look at it." The "looking at it" part relied on Obsidian's built-in file explorer or Graph View (Cmd+G) — generic Obsidian affordances, nothing KIOKU-specific.</p> <p>v0.6 adds <code>wiki/meta/dashboard.base</code>, using <a href="https://help.obsidian.md/bases" rel="noopener noreferrer">Obsidian 1.9+'s Bases feature</a> to surface nine live views:</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>View</th> <th>Shows</th> </tr> </thead> <tbody> <tr> <td>Hot Cache</td> <td>The recent-context memo from v0.5.1</td> </tr> <tr> <td>Active Projects</td> <td>Pages with <code>status: active</code> </td> </tr> <tr> <td>Recent Activity</td> <td>All wiki pages, sorted by last modified</td> </tr> <tr> <td>Concepts</td> <td>Pages with <code>type: concept</code> </td> </tr> <tr> <td>Design Decisions</td> <td>Pages with <code>type: decision</code> </td> </tr> <tr> <td>Analyses</td> <td>Pages with <code>type: analysis</code> </td> </tr> <tr> <td>Patterns</td> <td>Recurring pattern writeups</td> </tr> <tr> <td>Bugs</td> <td>Debugging memos</td> </tr> <tr> <td>Stale Pages</td> <td>Not modified in 30+ days (cleanup candidates)</td> </tr> </tbody> </table></div> <p>Pages are auto-classified via their frontmatter, so the dashboard updates live as the agent writes new entries or you manually edit status fields.</p> <h3> Why this matters more than it looks </h3> <p>This is KIOKU's <strong>first artifact that makes growth visible</strong>. Before v0.6, you could ingest PDFs and have hot cache carry context across compactions, but you couldn't really see KIOKU working for you. The dashboard surfaces "your wiki has 47 concepts, 12 design decisions, and 8 stale pages" in a way that felt missing.</p> <p>It's also the first screenshotable thing, which matters for the LP work happening in parallel. You can't put "an MCP tool that silently grows a Markdown tree" on a landing page.</p> <h2> 4. Delta tracking: stop paying for unchanged files </h2> <p>The quietest but maybe most practically useful change. The cron that ingests <code>raw-sources/</code> used to re-summarize every file every night, even if nothing had changed. For a vault with a stable set of research notes you edit occasionally, that meant <strong>the same PDF paid for its LLM summarization every day</strong>.</p> <p>v0.6 adds sha256-keyed delta tracking:</p> <ul> <li>Hash each file, stash hashes in <code>.raw-manifest.json</code> </li> <li>On the next cron run: if the hash matches, skip the LLM call</li> <li>If the content changed, the hash changes, and it gets re-ingested</li> </ul> <p>Uses <code>crypto.createHash('sha256')</code> from Node's stdlib. No new deps.</p> <h3> Measured impact </h3> <p>For my own vault with 38 markdown files under <code>raw-sources/articles/</code>, daily LLM calls dropped from <strong>3–5 per morning to 0–1</strong>. Most days, nothing has changed; the cron now notices and skips.</p> <p>The impact compounds with EPUB and DOCX ingestion (added in v0.5.0) — bigger source files mean bigger per-call cost, so skipping unchanged ones matters more as vaults grow.</p> <h2> 5. Formal security policy </h2> <p>v0.5 and earlier KIOKU already had the implementation half of "Hardened" — 8-layer defenses on EPUB/DOCX ZIPs, 14 vulnerabilities resolved with documented fixes, <code>applyMasks()</code> on every exported surface, a strict child-env allowlist, and so on. What it didn't have was the <strong>policy</strong> half.</p> <p>v0.6 fills that gap:</p> <ol> <li> <strong>CVE classification table</strong> — Critical / High / Medium / Low / Info each get a response SLA</li> <li> <strong>Safe Harbor clause</strong> — explicit legal protection for good-faith security research</li> <li> <strong>Coordinated Disclosure Timeline</strong> — 90-day rule (find → patch privately → public at day 90)</li> <li> <strong>Out of Scope definitions</strong> — what's not eligible for the disclosure process (social engineering, physical access, dev dependencies, etc.)</li> </ol> <h3> Why now </h3> <p>Phase C of the roadmap includes an LP β launch and a Discord soft-launch. If I'm going to invite external users, I need to be specific about <strong>where vulnerability reports go and how they'll be handled</strong>. Without Safe Harbor, researchers reasonably hesitate to report (legal exposure); without a disclosure timeline, they reasonably don't wait for a fix (public exposure).</p> <p>This is also the moment "Hardened LLM Wiki for Professionals" stops being positioning language and starts being policy. Implementation-hardened + documentation-hardened is where research/legal/enterprise users can actually start evaluating KIOKU as a tool they might sanction.</p> <h2> What's not in v0.6 (next up) </h2> <ul> <li> <strong>Visualizer HTML UI</strong> — the internal plumbing shipped in v0.6 invisibly. v0.7 α (early May target) will ship the visible pieces: a Timeline Player (animate wiki growth over time) and a Diff Viewer (compare two points in time, color-coded by added/modified/removed)</li> <li> <strong>Hook port for Gemini / Codex</strong> — the second phase of v0.6's multi-agent work. Automatic session logging and hot-cache injection become cross-agent so Gemini / Codex reach Claude Code parity on the automation layer</li> <li> <strong>LP β</strong> — in progress</li> <li> <strong>Discord soft launch</strong> — within days of release</li> <li> <strong>SECURITY.ja.md</strong> — three remaining sections still English-only, tracked in open-issues, will land by v0.7</li> </ul> <h2> Tests / audit </h2> <ul> <li>All Node + Bash suites green</li> <li> <code>npm audit</code> reports 0 vulnerabilities in runtime deps</li> <li>New test suites for plugin manifest integrity (plugin.json + marketplace.json), multi-agent symlink idempotency (safe to run <code>setup-multi-agent.sh</code> repeatedly), and delta tracking's two cases (re-ingest on content change, skip on unchanged hash)</li> </ul> <p>Full details in the <a href="https://github.com/megaphone-tokyo/kioku/releases/tag/v0.6.0" rel="noopener noreferrer">v0.6.0 release notes</a>.</p> <h2> Install / upgrade </h2> <p><strong>New install:</strong><br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code><span class="c"># Preferred</span> claude marketplace add megaphone-tokyo/kioku claude plugin <span class="nb">install </span>kioku@megaphone-tokyo <span class="c"># Or the .mcpb path (Claude Desktop-only users)</span> <span class="c"># Download kioku-wiki-0.6.0.mcpb (~9.2 MB) from Releases, drag into Settings → Extensions</span> </code></pre> </div> <p><strong>v0.5 → v0.6 upgrade:</strong><br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>git pull origin main bash scripts/setup-vault.sh <span class="c"># Idempotent; places dashboard.base</span> bash scripts/setup-multi-agent.sh <span class="c"># Optional; symlinks skills into Codex/OpenCode/Gemini</span> </code></pre> </div> <h2> The arc </h2> <p>v0.5 closed the loop on what KIOKU does internally. v0.6 opens it up externally — more install paths, more agents, first UI surface, first formal security policy.</p> <p>The next cycle (v0.7+) is the one I'm most uncertain about: moving from solo dogfooding to <strong>external user feedback</strong>. Everything in KIOKU has been shaped by me running into my own footguns on my own vault. There's a whole class of issues I can't see because I'm one user with one usage pattern. If you try v0.6 and something feels off, I'd love to hear about it.</p> <h2> Summary </h2> <ul> <li> <strong>v0.6.0</strong> is the "opening up" release, with multi-agent support as the main story</li> <li> <strong>Multi-agent</strong>: skills now run on Codex CLI, OpenCode, and Gemini CLI alongside Claude Code; the vault is shared, one second brain across all four agents</li> <li> <strong>Marketplace</strong>: <code>claude marketplace add megaphone-tokyo/kioku && claude plugin install kioku@megaphone-tokyo</code> </li> <li> <strong>Dashboard</strong>: first visible UI surface; 9 live views over your wiki via Obsidian Bases</li> <li> <strong>Delta tracking</strong>: sha256 gate drops my daily LLM calls from 3–5 to 0–1</li> <li> <strong>Security policy</strong>: CVE classification + Safe Harbor + 90-day coordinated disclosure; "Hardened" now has policy backing, not just code</li> <li>MIT licensed, feedback very welcome</li> </ul> <p><a href="https://github.com/megaphone-tokyo/kioku" rel="noopener noreferrer">https://github.com/megaphone-tokyo/kioku</a></p> <p>Read alongside the <a href="https://dev.to/megaphone/i-built-kioku-an-oss-memory-system-for-claude-code-3mhd">first</a>, <a href="https://dev.to/megaphone/i-brought-kioku-to-claude-desktop-one-mcpb-drag-no-node-setup-1n8l">second</a>, <a href="https://dev.to/megaphone/giving-kioku-my-claude-code-memory-oss-pdf-and-url-ingestion-5aio">third</a>, <a href="https://dev.to/megaphone/three-things-my-claude-code-memory-oss-was-quietly-getting-wrong-[slug]">fourth (v0.4)</a>, and <a href="https://dev.to/megaphone/kioku-v0-5-0-v0-5-1-[slug]">fifth (v0.5)</a> posts for the full KIOKU arc.</p> <p>Questions I'd love feedback on:</p> <ul> <li>For agent-portable skills: are you running into friction when the same skill payload has Claude-specific vs. Codex-specific vs. Gemini-specific conventions? Have you found a clean way to author "works everywhere" without lowest-common-denominator feature loss?</li> <li>For Obsidian dashboards: do you use <code>.base</code> files day-to-day, and have you found view patterns that surface growth (not just state)?</li> <li>For formal security policies on indie OSS: how do you balance "a real disclosure process" with "I'm one person who doesn't want to be paged at 3am"?</li> </ul> <h2> Other projects </h2> <h3> <a href="https://hello-from.dokokano.photo/" rel="noopener noreferrer">hello from the seasons.</a> </h3> <p>A gallery of seasonal photos I take, with a small twist: you can upload your own image and <strong>compose yourself into one of the season shots using AI</strong>. Cherry blossoms, autumn leaves, wherever. Built it for fun — photography is a long-running hobby, and mixing AI into the workflow felt right.</p> <p><em>Built by <a href="https://x.com/megaphone_tokyo" rel="noopener noreferrer">@megaphone_tokyo</a> — building things with code and AI. Freelance engineer, 10 years in. Tokyo, Japan.</em></p>
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。