Architecture

How ClaudeLink works under the hood: the per-agent MCP layer, the shared SQLite mesh, the message flow, and the agent lifecycle.

ClaudeLink has no daemon and no background service. Each agent session spawns its own short-lived claudelink-server process over MCP, and they coordinate through a single SQLite database on your machine. The Command Center launches with the first agent and persists across MCP restarts.

Reviewerclaudelink-serverDeveloperclaudelink-serverTesterclaudelink-serverArchitectclaudelink-serverSQLite mesh (WAL)~/.claudelink/nexus.dbCommand Center · 127.0.0.1:7878

Why SQLite

  • Zero configuration: a single file, with no server to run.
  • WAL mode handles concurrent readers and writers safely.
  • It survives process crashes with no data loss.
  • It is portable across macOS, Linux, and Windows.

Message flow

A single message moves through the mesh like this:

  1. Agent A calls send with a target role and a message.
  2. Its MCP server writes a row to the messages table.
  3. The auto-nudge scheduler (or the Claude Code Stop hook) wakes agent B.
  4. Agent B's server reads the unread rows and marks them read in one atomic step.
  5. Agent B receives the message and acts.

Agent lifecycle

Agents register with a role, process id, tty, and the terminal app they run in, which is auto-detected. A heartbeat updates last-seen every 30 seconds. Dead processes are checked and pruned at the next listing, so there is no manual cleanup; the Command Center also exposes a one-click Heal orphans for any tail rows left by an abrupt exit.

Because all of this lives on your machine and nothing is sent anywhere, the whole system is auditable end to end. See Security and privacy for the guarantees that follow from this design.