Public open-source project

N2N Nexus

Shares messages, tasks, and project notes across supported local clients.

Developers using more than one local client or IDE with shared project context.

n2n-nexusv0.4.2Apache-2.0MCPCollaborationAgents
N2N Nexus

Overview

  • Local coordination hub for multi-client development.
  • Keeps project messages, tasks, notes, and meeting history available across configured clients.
  • Runs locally so most users do not need to manage ports or hosts.

Common Uses

  • Share status between tools without copying chat transcripts.
  • Keep related repositories organized while working across frontend, backend, and tooling projects.
  • Record decisions and task status in one local place.

Requirements

  • Node.js >= 18
  • An MCP-capable client such as Claude Code, Claude Desktop, VS Code, Cursor, Windsurf, Zed, JetBrains, Theia, or Google Antigravity.
  • Local disk access for the Nexus user-data directory.

Install

  1. 1
    shell
    npx -y n2n-nexus

Configure

  1. 1
    json
    {
      "mcpServers": {
        "n2n-nexus": {
          "command": "npx",
          "args": [
            "-y",
            "n2n-nexus"
          ]
        }
      }
    }
  2. 2

    No --id or --host flag is required for normal use.

  3. 3

    Advanced storage override: n2n-nexus --root ./my-storage.

Tools / Commands

  • Register the active project before writing shared context.
  • Send and read messages between local clients working on the same project.
  • Create and update tasks so work can continue across tools.
  • Open shared project notes and meeting history when another client needs context.

Resources / Settings

  • Shared message rooms for project discussions.
  • Project registry for active workspaces and related repositories.
  • Local notes, meeting records, and task history stored on your machine.
  • Status views that show the active session and available projects.

FAQ

Frequently asked questions and troubleshooting guides.

No. Nexus elects a local coordinator and handles port conflicts automatically for normal setups.
Each client registers the active project, then posts updates or reads shared messages from the local hub.