Feature Request: Multi-Instance Claude Code Support for Agent Orchestration

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

PROBLEM STATEMENT:

When running multiple Claude Code instances on the same machine (claude -n epsilon, claude -n eta, claude -n victoria), MCP plugin notifications only route to the first instance started. Additional instances can send messages via MCP tools but cannot receive inbound notifications. This forces multi-agent architectures to use file-based workarounds for inter-agent and external communication, wasting tokens on polling loops and breaking the real-time event model.

Proposed Solution

Each named Claude Code instance (claude -n name) should independently maintain its own MCP plugin connections and receive notifications addressed to it. Options:

1. Per-instance MCP plugin processes — each instance spawns its own plugin server on a unique socket/port, with notifications routed by instance name
2. Instance-aware notification routing — a single plugin server tags notifications with the target instance name, and only the matching instance receives them
3. Shared notification bus with subscription — all instances connect to a shared MCP plugin, each subscribing to a topic/channel based on its name

Alternative Solutions

ALTERNATIVE SOLUTIONS:

• File-based inbox bridge (our current workaround): agents write JSON lines to shared files, other agents poll. Works but wastes tokens, adds latency, and loses messages on context compression.
• Custom MCP inbox server (issue #33575 approach): a self-hosted message queue MCP server where agents check/send/read. More robust than files but requires external infrastructure (database, custom server).
• Shared SQLite message table: lightweight version of the above, no external deps, but still requires polling.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

Use Case:
We run an automated trading system with multiple specialized Claude Code agents on one VPS:

• Epsilon (director): regime detection, posture control, monitoring
• Eta (health monitor): system diagnostics, bug sweeps
• Victoria (paper trader): independent strategy development

Additional Context

USE CASE EXAMPLE:

We run an automated prediction market trading system with 3 Claude Code agents on one Ubuntu VPS:

• Epsilon (director): runs 30-minute regime detection cycles, monitors all trading bots, adjusts risk posture, communicates with the human operator via Telegram
• Eta (health monitor): hourly system diagnostics — scans for errors, checks DB integrity, monitors process health, reports findings
• Victoria (paper trader): independently develops and tests trading strategies, manages a paper portfolio, reports hourly performance

The operator sends commands via Telegram. Only Epsilon receives them — Eta and Victoria are deaf to Telegram. To relay instructions to sub-agents, Epsilon writes to JSONL inbox files that agents poll every loop cycle. When Eta finds a critical issue, she writes to Epsilon's inbox file instead of sending a real-time alert.

Result: 91K tokens burned by Eta on a single task that produced zero output, partly because she couldn't receive real-time corrections when stuck on permission prompts. A proper multi-instance notification system would have allowed the operator to course-correct immediately.