Originally published on my Substack. I'm a Microsoft MVP based in Japan, writing in English about the AI agent systems I actually run in production.
🤖✍️ This article was co-written with AI — the AI agent (Claude Code) generated the draft based on actual collaborative work with Ebisuda, who then reviewed and edited it before publishing. Before starting to write this very article, the session posted a self-introduction in the "AI break room" described later in the piece.
This is about CCDB (Claude & Codex Discord Bridge), the open-source tool I built for running Claude and Codex from Discord.
The last time I wrote about this series was June 18, 2026 , in an article titled "Fire off tasks to Claude or Codex from your browser with one tap — how I added 'safe LAN exposure' to my DIY Discord Bridge," which covered v3.1.0.
About a month has passed since then. Before I knew it, the version had gone from v3.1.0 → v3.2.4 , and it had quietly become a different tool. Even I found myself thinking "wait, where did I leave off last time?" — so this post is a roundup of what changed over the past month. This time, it's all free.
GitHub: https://github.com/ebibibi/claude-code-discord-bridge Just send a message from the Discord app on your phone, and behind the scenes the Claude Code or Codex CLI springs into action — reading and writing code, running tests, even opening a PR. It's a tool that turns Discord into a doorway for AI coding.
One thread = one AI session. You can run a new feature in thread A, a PR review in thread B, and documentation in thread C, all in parallel
Each session is isolated in its own git worktree , so running them simultaneously doesn't cause conflicts
The backend can be switched between Claude and Codex per thread via /backend
In the previous article, I described adding a feature that lets you "safely expose only the safe entry points of your own machine's API from outside, while keeping the dangerous parts closed" — that is, exposing /api/ingest externally. That's what made it possible to say "send this whole page to the AI" from a browser extension.
So what's changed since then? There are three headline items.
__ *
This is the biggest change of the past month.
Until now, multiple AI sessions running in parallel could only post self-introductions to a shared bulletin board called the "AI Lounge (break room)." A session would post "I'm currently looking at a bug in the XXX repo," but another session reading that post couldn't actually do anything concrete about it. It was basically just talking to itself on a bulletin board.
In v3.2.0, four layers were added on top of this. And all of them are designed to be "enabled by default, dormant until sessions actually overlap" (Zero-Config).
GET /api/sessions returns a list of who's currently alive, where, and doing what. It even surfaces sessions that were just born, before anything has been recorded to the DB yet — because the sessions most likely to collide are exactly the ones at that moment. GET /api/threads/{id}/messages also lets you peek directly at the conversation in another thread.
Before starting work, a session can place an "advisory lock" reservation tag on a resource.
POST /api/claims resource: "repo:ccdb#issue-123"
If it succeeds, you get **201**
If someone already holds it, you get **409** — along with **who holds it and for what purpose**
"Couldn't get the lock. Guess I'll do something else instead" can now happen entirely between AI sessions, without human involvement. Locks have a TTL (2 hours by default), so a dead session can't hold a resource hostage forever. This is the "cheap half" of coordination — it uses no AI calls at all (i.e., consumes no tokens).
POST /api/threads/{id}/message lets one session deliver a message directly to another live session. mode=queue waits for the other session's turn to finish, while mode=interrupt breaks in with "stop right now."
What's interesting is that the decision rule for who continues and who steps back is embedded in the shared prompt. The order is deterministic: "already committed / has a PR > still investigating" → "whoever started earlier" → "whoever has the smaller thread ID." Since both sides run the same calculation, they arrive at the same conclusion , so it never gets stuck in an endless "after you" / "no, after you" loop. Whichever session steps back always pushes its own branch first before backing off.
The three mechanisms above all assume a session says something explicitly. This fourth one catches collisions no one declared.
Each session's file writes (Write / Edit / MultiEdit) are logged, and if two sessions write to the same file within 15 minutes , it's treated as a collision, and a warning is posted to the break room and both threads. The key point here is checking by file path, not working directory. On a single-user machine, all sessions share the same $HOME , so comparing by directory would flag every pair as colliding , making the check meaningless. I've been squashing these "looks reasonable but is actually useless" traps one by one.
Incidentally, this very articlewas written on top of this mechanism. The session that started writing first posted a self-introduction in the break room saying "I'm going to write an article about CCDB," checked whether any other session was touching the same repo, claimed the work, and then started writing. It's a case of writing an article about a feature using that very feature.
__ *
Discord threads get auto-archived after a period of inactivity and disappear from the sidebar (hidden, not deleted). Titles are often generic too, so "which thread was that thing I did before?" tended to become a missing-persons case.
So I added two-tier search. Neither one uses a single AI token.
**Tier 1: /search **
CCDB already stores the "first prompt" of each session as a summary, so this is a LIKE search against that. No new storage, no re-indexing needed. Each matching thread comes with a Discord deep link , so even archived threads can be reopened with one click.
**Tier 2: /search body:True (full-text search)**
For when you want to find a keyword that appeared **partway through a conversation** , not in the first prompt. Since Claude Code writes out the entire conversation to **~/.claude/projects/…jsonl** , this **grep** s through those files (it doesn't use **shell=True** ; the keyword is passed as a literal string after **--** , so it can't be abused as a flag or regex). I actually validated this against **709MB across 5,400 files** of real data — each query completes within 2 seconds and matches both Japanese and English.
Rather than "having the AI search," it's "using ordinary search to pull up the traces the AI already left behind." Not burning tokens is my favorite part of this.
__ *
This follows on from the /api/ingest feature (sending a whole page from the browser) covered in the previous article.
Consider a case like replying to the same long Teams thread for months on end. Since CCDB is designed to spin up a new session for every ingest call, it had to resend the entire thread every time just to convey context. Sending months' worth of history every single time was way too wasteful.
So now, for each stable key the client specifies (e.g., the ID of the first message in a Teams thread), the server keeps a running summary.
Before sending, the client calls GET /api/ingest/summary?key=… to fetch the "stored summary" and "how far it's already been read (marker)"
The client exports and sends only the diff since then
The session gets full context from "stored summary + diff," and once done, updates and saves the summary
The marker advances based on the server's own ingest records, so the read position only moves forward once the summary has actually been saved. If a session fails, it can just resend the same diff without dropping any messages. And of course, if you don't specify a key, everything works exactly as before (Zero-Config).
From "send the full thing every time" to "diff plus server-side memory." It's a quiet change, but it pays off over long-term operation. __ *
Codex model/reasoning strength is now configurable : dropped the hardcoded fixed model gpt-5.4 in favor of following the Codex CLI's own default when no model is specified (so it won't silently go stale). /effort also lets you switch reasoning strength per backend
/api/spawn can now post attachments to a new thread : when watching a Forgejo issue/PR to spin up a thread, issue attachments are now carried over and visible too
(Security fix) Closed a hole in mention-only channels : fixed a path where, in channels configured to "only respond when @mentioned," a thread manually created by a human could unintentionally spawn a session
Squashed several minor parser bugs, including one where the Codex backend's progress display would get stuck showing "Running… Ns elapsed" forever
__ *
A month ago, things were at the stage of "made it possible to safely poke the entry point from outside." Since then:
Multiple AIs now notice each other, yield to each other, and talk it out to avoid collisions when needed
Past work can be dug back up without spending tokens
Long conversations can continue with just diffs
It's been a month that moved straight in the direction of "keep lots of AI sessions running without incidents, without a human having to watch over them."
What's fun is that this coordination feature directly powers CCDB's own development. New CCDB features get built by multiple AI sessions working in parallel through CCDB itself, exchanging messages in the break room like "I'm working on that right now, hold on a sec." There's a real sense of the tool becoming its own scaffolding for building itself, and that's the part I enjoy most.
It's all open source, so take a look if you're curious.