tmux-claude MCP Server

tmux-claude MCP Server

Enables hierarchical orchestration of Claude instances via tmux with a bridge pattern architecture reducing memory usage by 85%.

Category
访问服务器

README

tmux-claude MCP Server

<p align="center"> <img src="logos/logo.png" alt="tmux-claude MCP Server" width="200"> </p>

<p align="center"> <a href="https://github.com/michael-abdo/tmux-claude-mcp-server/blob/master/LICENSE"> <img src="https://img.shields.io/badge/license-MIT-blue.svg" alt="MIT License"> </a> <a href="https://www.npmjs.com/package/tmux-claude-mcp-server"> <img src="https://img.shields.io/npm/v/tmux-claude-mcp-server.svg" alt="npm version"> </a> <a href="https://github.com/michael-abdo/tmux-claude-mcp-server/actions"> <img src="https://img.shields.io/github/actions/workflow/status/michael-abdo/tmux-claude-mcp-server/test.yml?branch=master" alt="Build Status"> </a> <a href="https://nodejs.org"> <img src="https://img.shields.io/badge/node-%3E%3D18.0.0-brightgreen.svg" alt="Node.js Version"> </a> <a href="https://github.com/michael-abdo/tmux-claude-mcp-server"> <img src="https://img.shields.io/badge/PRs-welcome-brightgreen.svg" alt="PRs Welcome"> </a> <a href="https://github.com/michael-abdo/tmux-claude-mcp-server/issues"> <img src="https://img.shields.io/github/issues/michael-abdo/tmux-claude-mcp-server.svg" alt="GitHub Issues"> </a> </p>

A highly efficient Model Context Protocol (MCP) server enabling hierarchical orchestration of Claude instances via tmux. Features a bridge pattern architecture that reduces memory usage by 85% compared to traditional multi-server approaches.

📸 Screenshots

Demo 1 - Hierarchical Instance Management Hierarchical orchestration showing Executive, Manager, and Specialist instances working together

Demo 2 - Real-time Monitoring Dashboard Web-based monitoring dashboard displaying active instances and system metrics

🤖 For Claude Code Instances

New to this repository? If you're a Claude Code instance, start with the Claude Getting Started Guide for a quick orientation and practical examples.

Overview

Architecture Innovation

Due to MCP's documented 1:1 stdio architecture, multiple Claude instances cannot directly access MCP tools. Our bridge pattern solution:

  • Single shared MCP server process (50-70MB total)
  • Lightweight bridge for multi-instance access via Bash
  • 85% memory reduction vs spawning separate servers
  • Zero race conditions with centralized state management

Core MCP Tools

  • spawn: Create new Claude instances with roles (Executive/Manager/Specialist)
  • send: Send text/prompts to instances
  • read: Read output from instances
  • list: List active instances with filtering
  • terminate: Stop instances and optionally their children

New Features

  • VM Integration: Complete cloud VM management for development environments
  • Scheduled Continue: Schedule "Plz continue" messages to all tmux sessions at specified times
  • Workspace Modes: Support for isolated (default) and shared workspace modes
  • Git Integration: Automatic branch management for shared workspaces
  • Conflict Detection: Proactive identification of merge conflicts
  • MCP Git Tools: 5 new tools for git operations (git_status, git_branch, etc.)
  • AI Conflict Resolution: Intelligent merge conflict resolution using Claude
  • Performance Optimizations: Parallel spawning, message batching, caching
  • Monitoring Dashboard: Real-time web dashboard for system monitoring

Project Structure

tmux-claude-mcp-server/
├── README.md              # Project overview and usage
├── LICENSE                # MIT license
├── package.json           # Node.js dependencies
├── package-lock.json      # Locked dependencies
├── .gitignore            # Version control ignore patterns
├── src/                   # Core source code
│   ├── simple_mcp_server.js    # Main MCP server
│   ├── instance_manager.js     # Instance lifecycle management
│   ├── mcp_tools.js            # MCP tool implementations
│   ├── tmux_interface.js       # tmux integration layer
│   ├── reliable_tmux_sender.js # High-reliability message delivery
│   ├── orchestration/          # Orchestration components
│   ├── dashboard/              # Web monitoring dashboard
│   ├── role_templates/         # Standardized role templates
│   └── workflow/               # Workflow orchestration system
│       ├── actions/            # Modular action implementations
│       ├── workflow_engine.cjs # Main workflow engine
│       └── run_workflow.cjs    # Workflow runner CLI
├── scripts/               # Utility scripts
│   ├── mcp_bridge.js           # Bridge for multi-instance MCP access
│   ├── scheduled_continue.js   # Schedule "Plz continue" messages
│   ├── check/                  # Session checking utilities
│   ├── restart/                # Session restart utilities
│   ├── utils/                  # Shared utilities
│   │   └── time_parser.js     # Time parsing for scheduling
│   └── api/                    # API scripts for monitoring
├── docs/                  # Documentation
│   ├── CHANGELOG.md             # Version history
│   ├── CONTRIBUTING.md          # Contribution guidelines
│   ├── WORKFLOW_GUIDE.md        # Workflow system guide
│   ├── CLAUDE_GETTING_STARTED.md    # Quick start for Claude instances
│   ├── DOCUMENTATION_INDEX.md       # Documentation map
│   ├── scheduled_continue/          # Scheduled continue feature docs
│   │   ├── CLI_INTERFACE_DESIGN.md
│   │   ├── TIME_FORMAT_SPECIFICATION.md
│   │   └── SCHEDULING_MECHANISM_ANALYSIS.md
│   ├── analysis/          # Technical analysis & findings
│   ├── archive/           # Historical documentation
│   └── guides/            # User guides and specifications
├── tests/                 # Test suites
│   ├── test_workflow_standalone.cjs  # Standalone workflow tests
│   ├── unit/             # Unit tests
│   ├── integration/      # Integration tests
│   ├── e2e/              # End-to-end tests
│   └── performance/      # Performance benchmarks
├── workflows/             # Workflow system
│   ├── README.md              # Workflow documentation
│   ├── CURRENT_STATUS.md      # Current status and usage
│   ├── library/               # Reusable workflow components
│   ├── examples/              # Example workflows
│   ├── tests/                 # Workflow test files
│   ├── scripts/               # Workflow utilities
│   ├── state/                 # Workflow state storage
│   └── user/                  # User-created workflows
├── state/                # Default state directory
├── config/               # Configuration files
├── logs/                 # Log directory
└── vm-integration/       # Cloud VM management
    ├── README.md              # VM integration documentation
    ├── vm_manager.js          # Core VM management class
    ├── vm_cli.js              # Command-line interface
    ├── vm_mcp_tools.js        # MCP tools integration
    ├── integrate_vm_mcp.js    # MCP server integration
    ├── setup-scripts/         # VM initialization scripts
    │   └── claude-dev-setup.sh
    └── tests/                 # VM integration tests
        └── test_vm_integration.js

Architecture

  • External State Store: JSON file-based registry for Phase 1, Redis-ready for Phase 2+
  • Project Isolation: Each Claude instance uses --project flag for conversation isolation
  • Role-Based Access: Specialists have NO access to MCP tools, only Executive/Manager can orchestrate
  • Hierarchical Naming: exec_1, mgr_1_1, spec_1_1_1 for clear parent-child relationships
  • Nearly-Free Recovery: Restart instances using --continue flag

Code Harvest

This implementation harvests and adapts ~20-30% of the existing tmux-manager codebase:

Harvested Components

  • tmux_interface.pysrc/tmux_interface.js - Core tmux operations
  • instance.pysrc/instance_manager.js - Instance lifecycle management
  • manager.pysrc/instance_manager.js - Registry and coordination
  • session_manager.pysrc/instance_manager.js - Session operations

Discarded Components (60-70%)

  • All CLI interfaces
  • Pattern matching/monitoring systems
  • Event bus architecture
  • Configuration management
  • Layout systems

Installation

cd tmux-claude-mcp-server
npm install

Configuration (REQUIRED)

CRITICAL: You MUST configure the MCP server globally for all Claude instances:

claude mcp add tmux-claude -s user node /path/to/tmux-claude-mcp-server/src/simple_mcp_server.js

Important notes:

  • The -s user flag is REQUIRED for hierarchical orchestration to work
  • This makes the MCP server available to ALL Claude instances
  • Without this, spawned instances will NOT have access to MCP tools
  • See MCP Configuration Guide for detailed information

Verify configuration:

claude mcp list
# Should show: tmux-claude: node /path/to/simple_mcp_server.js

Usage

The MCP server runs automatically when Claude starts (after proper configuration above).

Tool Examples

Spawn an Executive

{
  "name": "spawn",
  "arguments": {
    "role": "executive",
    "workDir": "/jobs/auth_system",
    "context": "# Executive: Auth System\\n\\nYou are responsible for orchestrating the implementation of a JWT authentication system..."
  }
}

Executive Spawns Manager

{
  "name": "spawn", 
  "arguments": {
    "role": "manager",
    "workDir": "/jobs/auth_system",
    "context": "# Manager: Auth Implementation\\n\\nPlan and coordinate the JWT auth system implementation...",
    "parentId": "exec_1"
  }
}

Manager with Shared Workspace (NEW)

{
  "name": "spawn",
  "arguments": {
    "role": "manager",
    "workDir": "/jobs/auth_system", 
    "context": "# Manager: Feature Implementation\\n\\nCoordinate multiple specialists...",
    "parentId": "exec_1",
    "workspaceMode": "shared"  // Enable git integration
  }
}

Manager Spawns Specialist

{
  "name": "spawn",
  "arguments": {
    "role": "specialist", 
    "workDir": "/jobs/auth_system",
    "context": "# Specialist: User Model\\n\\nImplement the User model with Mongoose...",
    "parentId": "mgr_1_1"
  }
}

Send Task to Specialist

{
  "name": "send",
  "arguments": {
    "instanceId": "spec_1_1_1",
    "text": "Please implement the User model with email, password, and timestamps fields"
  }
}

Read Specialist Output

{
  "name": "read",
  "arguments": {
    "instanceId": "spec_1_1_1",
    "lines": 50
  }
}

List All Active Instances

{
  "name": "list",
  "arguments": {}
}

List Manager's Specialists

{
  "name": "list",
  "arguments": {
    "parentId": "mgr_1_1"
  }
}

Terminate Completed Specialist

{
  "name": "terminate",
  "arguments": {
    "instanceId": "spec_1_1_1"
  }
}

State Management

External State Store (Phase 1)

Located at ./state/instances.json:

{
  "instances": {
    "exec_1": {
      "instanceId": "exec_1",
      "role": "executive",
      "parentId": null,
      "sessionName": "claude_exec_1",
      "projectDir": "/jobs/auth_system/exec_1",
      "paneTarget": "claude_exec_1:0.0",
      "status": "active",
      "created": "2024-01-01T10:00:00Z",
      "children": ["mgr_1_1"]
    }
  }
}

Instance Directory Structure

/jobs/auth_system/
├── exec_1/
│   ├── CLAUDE.md              # Executive context
│   └── project files...
├── mgr_1_1/  
│   ├── CLAUDE.md              # Manager context
│   └── project files...
└── spec_1_1_1/
    ├── CLAUDE.md              # Specialist context
    └── implementation files...

Error Recovery

The server implements nearly-free recovery using Claude's --continue flag:

{
  "name": "restart",
  "arguments": {
    "instanceId": "spec_1_1_1"
  }
}

This will:

  1. Check if instance is actually dead
  2. Recreate tmux session in same project directory
  3. Launch claude --project . --continue
  4. Claude automatically resumes where it left off

Role-Based Access Control

  • Executive: Full access to all MCP tools
  • Manager: Full access to all MCP tools
  • Specialist: NO access to MCP tools (uses standard Claude tools only)

The server enforces this by checking the caller's role and rejecting MCP tool calls from Specialists.

Integration with Claude SDK

Each spawned instance:

  • Uses --project <dir> for conversation isolation
  • Gets unique project directory: ~/.claude/projects/-jobs-auth_system-<instance_id>/
  • Maintains separate conversation history and todos
  • Can be monitored via read-only access to Claude's todo files

Phase Evolution

  • Phase 1: Sequential execution, 1 Executive → 1 Manager → 1 Specialist
  • Phase 2: Limited parallelism, 2-3 Specialists per Manager
  • Phase 3: Full parallelism, multiple Managers and Specialists

The MCP interface is designed to support all phases without code changes - only configuration differences.

Scheduled Continue Feature

The Scheduled Continue feature allows you to schedule "Plz continue" messages to all tmux sessions at a specified time. This is useful for automating session management and ensuring work resumes at specific times.

Basic Usage

# Schedule in 30 minutes
node scripts/scheduled_continue.js "+30m"

# Schedule at 3:30 PM today
node scripts/scheduled_continue.js "15:30"

# Schedule at 9:45 AM with AM/PM format
node scripts/scheduled_continue.js "9:45am"

# Schedule using natural language
node scripts/scheduled_continue.js "in 2 hours"

Advanced Options

# Custom message
node scripts/scheduled_continue.js "+1h" -m "Time to review progress"

# Dry run (test without executing)
node scripts/scheduled_continue.js "+5m" --dry-run

# Verbose logging
node scripts/scheduled_continue.js "+15m" --verbose

# Show help
node scripts/scheduled_continue.js --help

Supported Time Formats

  • Relative: +30m, +2h, +90m
  • 24-hour: 15:30, 09:45, 23:59
  • 12-hour: 3:30pm, 9:45am, 11:59PM
  • Natural language: "in 30 minutes", "in 2 hours"

Important Notes

  • The process must remain running until execution time
  • System sleep/hibernate may interrupt scheduling
  • Maximum scheduling window is 24 hours
  • Sessions are re-validated at execution time
  • Uses high-reliability message delivery

For detailed documentation, see:

Testing

npm test                         # Run all tests
./scripts/run_all_tests.sh      # Run comprehensive test suite

Development

npm run dev  # Start with file watching

Architecture Documents

For complete implementation details, see:

  • docs/main/tmux-manager-MCP.md - MCP server specification
  • docs/main/tmux-claude-implementation.md - Complete architecture
  • docs/main/tmux-mvp-implementation.md - Phase 1 MVP approach
  • docs/GIT_INTEGRATION_GUIDE.md - Git integration and workspace modes
  • docs/WORKSPACE_MODES.md - Detailed workspace mode documentation
  • docs/GIT_INTEGRATION_REFINEMENT_PLAN.md - Technical implementation details

推荐服务器

Baidu Map

Baidu Map

百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。

官方
精选
JavaScript
Playwright MCP Server

Playwright MCP Server

一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。

官方
精选
TypeScript
Magic Component Platform (MCP)

Magic Component Platform (MCP)

一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。

官方
精选
本地
TypeScript
Audiense Insights MCP Server

Audiense Insights MCP Server

通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。

官方
精选
本地
TypeScript
VeyraX

VeyraX

一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。

官方
精选
本地
graphlit-mcp-server

graphlit-mcp-server

模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。

官方
精选
TypeScript
Kagi MCP Server

Kagi MCP Server

一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。

官方
精选
Python
e2b-mcp-server

e2b-mcp-server

使用 MCP 通过 e2b 运行代码。

官方
精选
Neon MCP Server

Neon MCP Server

用于与 Neon 管理 API 和数据库交互的 MCP 服务器

官方
精选
Exa MCP Server

Exa MCP Server

模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。

官方
精选