KIOKU v0.6.0: multi-agent support — same vault across Claude / Codex / OpenCode / Gemini CLI

Context

I've been building KIOKU — a memory / second-brain OSS for Claude Code and Claude Desktop. The previous post covered v0.5.0 + v0.5.1, the "ingest → persist" pair: unified document ingestion and a hot cache that survives Claude Code's compaction.

v0.6.0 (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 opening KIOKU up externally. The headline change:

KIOKU is no longer Claude-only. 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.

Alongside that, v0.6 ships four more changes:

• 🔀 Multi-agent support (the main story) — Claude Code / Codex CLI / OpenCode / Gemini CLI all share the same vault
• 📦 Claude Code plugin marketplace — one-command install
• 📊 Obsidian Bases dashboard — 9 live views over your wiki (first real UI surface)
• 🔁 Raw Markdown delta tracking — sha256-gated so unchanged files stop costing you LLM calls
• 🛡 Formal security policy — CVE classification, Safe Harbor, 90-day coordinated disclosure

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.

https://github.com/megaphone-tokyo/kioku

1. Multi-agent: same vault, any agent

This is the biggest directional change in v0.6 and the one I want to spend the most words on.

Before / After

Before (v0.5):

[Claude Code] → KIOKU skills → MCP → Vault (second brain)

[Codex CLI / OpenCode / Gemini CLI] → ❌ (skills don't install there)

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.

After (v0.6):

              ┌── Claude Code ──┐
              ├── Codex CLI ────┤
 [you] ─────→ ┤                 ├──→ KIOKU skills → Vault (shared file-level)
              ├── OpenCode ─────┤
              └── Gemini CLI ───┘

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.

Scope note: 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).

Setup

One script:

bash scripts/setup-multi-agent.sh
# symlinks the skills into:
#   ~/.codex/skills/kioku/
#   ~/.opencode/skills/kioku/
#   ~/.gemini/skills/kioku/

Rerun anytime — it's idempotent and the test suite pins that.

Why this was technically possible

Honestly, there was no longer a good reason to keep KIOKU Claude-only. The skill layer — the set of instructions that teach an agent how to manage a Karpathy-style Wiki — had always been just Markdown + frontmatter. We had maxTurns and a few other Claude Code-specific fields, but they weren't load-bearing.

The core extractor is Node stdlib + Bash. The MCP server depends only on @modelcontextprotocol/sdk 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."

Three use cases this unlocks

(1) Agent lock-in avoidance. 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.

(2) Cross-agent workflows. 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).

(3) Comparative evaluation. 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.

What I explicitly didn't do

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 one skill definition, symlinked into four locations. A fifth or sixth agent in the future means adding a symlink target, not a fork.

Personal dogfooding note

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.

2. Plugin marketplace: the install surface

Before v0.6, installing KIOKU meant downloading an .mcpb 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.

v0.6 registers KIOKU in the Claude Code plugin marketplace:

claude marketplace add megaphone-tokyo/kioku
claude plugin install kioku@megaphone-tokyo

The .mcpb 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.

3. Obsidian Bases dashboard: the first real UI surface

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.

v0.6 adds wiki/meta/dashboard.base, using Obsidian 1.9+'s Bases feature to surface nine live views:

View	Shows
Hot Cache	The recent-context memo from v0.5.1
Active Projects	Pages with status: active
Recent Activity	All wiki pages, sorted by last modified
Concepts	Pages with type: concept
Design Decisions	Pages with type: decision
Analyses	Pages with type: analysis
Patterns	Recurring pattern writeups
Bugs	Debugging memos
Stale Pages	Not modified in 30+ days (cleanup candidates)

Pages are auto-classified via their frontmatter, so the dashboard updates live as the agent writes new entries or you manually edit status fields.

Why this matters more than it looks

This is KIOKU's first artifact that makes growth visible. 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.

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.

4. Delta tracking: stop paying for unchanged files

The quietest but maybe most practically useful change. The cron that ingests raw-sources/ 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 the same PDF paid for its LLM summarization every day.

v0.6 adds sha256-keyed delta tracking:

• Hash each file, stash hashes in .raw-manifest.json
• On the next cron run: if the hash matches, skip the LLM call
• If the content changed, the hash changes, and it gets re-ingested

Uses crypto.createHash('sha256') from Node's stdlib. No new deps.

Measured impact

For my own vault with 38 markdown files under raw-sources/articles/, daily LLM calls dropped from 3–5 per morning to 0–1. Most days, nothing has changed; the cron now notices and skips.

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.

5. Formal security policy

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, applyMasks() on every exported surface, a strict child-env allowlist, and so on. What it didn't have was the policy half.

v0.6 fills that gap:

1. CVE classification table — Critical / High / Medium / Low / Info each get a response SLA
2. Safe Harbor clause — explicit legal protection for good-faith security research
3. Coordinated Disclosure Timeline — 90-day rule (find → patch privately → public at day 90)
4. Out of Scope definitions — what's not eligible for the disclosure process (social engineering, physical access, dev dependencies, etc.)

Why now

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 where vulnerability reports go and how they'll be handled. Without Safe Harbor, researchers reasonably hesitate to report (legal exposure); without a disclosure timeline, they reasonably don't wait for a fix (public exposure).

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.

What's not in v0.6 (next up)

• Visualizer HTML UI — 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)
• Hook port for Gemini / Codex — 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
• LP β — in progress
• Discord soft launch — within days of release
• SECURITY.ja.md — three remaining sections still English-only, tracked in open-issues, will land by v0.7

Tests / audit

• All Node + Bash suites green
• npm audit reports 0 vulnerabilities in runtime deps
• New test suites for plugin manifest integrity (plugin.json + marketplace.json), multi-agent symlink idempotency (safe to run setup-multi-agent.sh repeatedly), and delta tracking's two cases (re-ingest on content change, skip on unchanged hash)

Full details in the v0.6.0 release notes.

Install / upgrade

New install:

# Preferred
claude marketplace add megaphone-tokyo/kioku
claude plugin install kioku@megaphone-tokyo

# Or the .mcpb path (Claude Desktop-only users)
# Download kioku-wiki-0.6.0.mcpb (~9.2 MB) from Releases, drag into Settings → Extensions

v0.5 → v0.6 upgrade:

git pull origin main
bash scripts/setup-vault.sh            # Idempotent; places dashboard.base
bash scripts/setup-multi-agent.sh      # Optional; symlinks skills into Codex/OpenCode/Gemini

The arc

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.

The next cycle (v0.7+) is the one I'm most uncertain about: moving from solo dogfooding to external user feedback. 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.

Summary

• v0.6.0 is the "opening up" release, with multi-agent support as the main story
• Multi-agent: skills now run on Codex CLI, OpenCode, and Gemini CLI alongside Claude Code; the vault is shared, one second brain across all four agents
• Marketplace: claude marketplace add megaphone-tokyo/kioku && claude plugin install kioku@megaphone-tokyo
• Dashboard: first visible UI surface; 9 live views over your wiki via Obsidian Bases
• Delta tracking: sha256 gate drops my daily LLM calls from 3–5 to 0–1
• Security policy: CVE classification + Safe Harbor + 90-day coordinated disclosure; "Hardened" now has policy backing, not just code
• MIT licensed, feedback very welcome

https://github.com/megaphone-tokyo/kioku

Read alongside the first, second, third, fourth (v0.4), and fifth (v0.5) posts for the full KIOKU arc.

Questions I'd love feedback on:

• 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?
• For Obsidian dashboards: do you use .base files day-to-day, and have you found view patterns that surface growth (not just state)?
• 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"?

Other projects

hello from the seasons.

A gallery of seasonal photos I take, with a small twist: you can upload your own image and compose yourself into one of the season shots using AI. Cherry blossoms, autumn leaves, wherever. Built it for fun — photography is a long-running hobby, and mixing AI into the workflow felt right.

---

Built by @megaphone_tokyo — building things with code and AI. Freelance engineer, 10 years in. Tokyo, Japan.