CodeServer MCP

CodeServer MCP

Provides stateful development sessions for code-server, enabling persistent shells, background processes, sandboxed file operations, and file watching through MCP.

Category
Visit Server

README

CodeServer MCP

A production-oriented Model Context Protocol server for code-server, built around stateful development sessions rather than stateless file operations.

Architecture

Core Modules

workspace/ — Sandboxed file operations scoped to WORKSPACE_ROOT

  • read.py — Read files with optional line-range slicing
  • write.py — Atomic file writes (create/overwrite)
  • patch.py — Targeted edits via unified diff or find/replace (never resend the whole file)
  • search.py — Ripgrep-based search with structured results
  • tree.py — Recursive directory listing (respects .gitignore-style ignore rules)
  • watch.py — Async file watching; detect changes made by the editor, git, build tools

terminal/ — Persistent shells & background processes

  • pty.py — Real pseudo-terminal wrapper (ptyprocess) for authentic terminal behavior (colors, pagers, history)
  • shell.py — Persistent shell sessions that survive crashes/restarts
  • process.py — Background process manager with log capture

util/

  • paths.py — Workspace sandboxing: every file operation goes through resolve_path() which proves the result still lives inside WORKSPACE_ROOT
  • diff.py — Unified diff helpers for generating and applying patches

Key Design Decisions

  1. Real PTYs, not subprocesses

    • Shells are real pseudo-terminals (ptyprocess), so programs that check isatty() behave naturally.
    • Output includes ANSI colors, spinner sequences, and pager control codes.
    • Shell history and readline state persist across calls.
  2. Stateful vs. Stateless

    • Unlike generic filesystem MCP servers, shells and processes are first-class, long-lived entities.
    • A shell can run npm run dev, and the dev server keeps running. Later calls can read its output, resize its terminal, or send it signals.
    • Session recovery on restart: PTY metadata is stored in SQLite so crashed dev servers can be reconnected.
  3. Sandboxing

    • Every workspace operation (read/write/patch/search/tree/watch) goes through util.paths.resolve_path().
    • All paths are canonicalized and checked to be within WORKSPACE_ROOT — symlinks cannot escape.
  4. Patching, not Overwriting

    • replace_text() and apply_patch() let Claude make surgical edits without resending entire files.
    • Diffs are generated and returned so clients (Claude) can see what changed.
  5. Async-first

    • All I/O is async (asyncio, aiofiles, aiosqlite).
    • Long-lived watches and process log tailing don't block.

Installation

Docker (Recommended)

docker-compose up -d
# MCP server now listens on localhost:8080

Local (Python 3.12+)

python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
pip install -r requirements.txt
export WORKSPACE_ROOT=/path/to/code
export MCP_PORT=8080
python app.py

Environment Variables

  • MCP_HOST (default: 0.0.0.0) — Listen address
  • MCP_PORT (default: 8080) — Listen port
  • WORKSPACE_ROOT (default: /workspace) — Sandbox root; all file operations must stay within this
  • RG_BIN (default: rg) — Path to ripgrep binary if not on PATH
  • LOG_LEVEL (default: info) — Uvicorn log level

MCP Tools

Workspace

  • workspace_read_file(path, start_line, end_line) — Read a file (with optional line range)
  • workspace_write_file(path, content, mode, create_dirs) — Write or create a file
  • workspace_replace_text(path, old, new, expected_count) — Find and replace (safe, requires uniqueness)
  • workspace_apply_patch(path, diff_text) — Apply a unified diff
  • workspace_search(pattern, path, glob, case_sensitive, fixed_string, max_results) — Ripgrep-based search
  • workspace_tree(path, max_depth, max_entries) — Directory listing
  • workspace_watch_start(path) — Start watching a directory for changes
  • workspace_watch_poll(watch_id, timeout) — Poll a watch for events
  • workspace_watch_stop(watch_id) — Stop a watch
  • workspace_watch_list() — List active watches

Terminal

  • terminal_shell_create(cwd) — Create a new persistent PTY shell
  • terminal_shell_execute(shell_id, command, timeout) — Run a command in a shell
  • terminal_shell_read(shell_id) — Read pending output (non-blocking)
  • terminal_shell_resize(shell_id, rows, cols) — Resize the terminal
  • terminal_shell_list() — List active shells
  • terminal_shell_terminate(shell_id) — Kill a shell
  • terminal_process_start(command, cwd, proc_id) — Start a background process
  • terminal_process_logs(proc_id, lines) — Read process logs
  • terminal_process_stop(proc_id, timeout) — Stop a process
  • terminal_process_list() — List active processes

Usage Examples

Create a Persistent Dev Server Shell

# Create a shell
shell_resp = await terminal_shell_create(cwd=".")
shell_id = shell_resp["id"]  # "shell-abc123"

# Start a dev server (runs in background)
await terminal_shell_execute(shell_id, "npm run dev")

# Read output later
output = await terminal_shell_read(shell_id)
print(output["output"])  # "VITE ready in 314ms..."

# Even if the MCP server crashes, the shell survives.
# On restart, terminal_shell_list() will still see it.

Edit a File Without Resending It

# Read a file
file_resp = workspace_read_file("src/app.py")
before = file_resp["content"]

# Client (or Claude) modifies it locally
after = before.replace("const x = 1", "const x = 2")

# Send only the diff
diff = generate_unified_diff(before, after, "src/app.py")
patch_resp = await workspace_apply_patch("src/app.py", diff)
print(patch_resp["diff"])  # Shows what changed

Watch for Changes

# Start watching the src/ directory
watch_resp = await workspace_watch_start("src")
watch_id = watch_resp["id"]

# Do work (edit files, run git pull, etc.)
await asyncio.sleep(5)

# Poll for changes
poll_resp = await workspace_watch_poll(watch_id, timeout=1)
for event in poll_resp["events"]:
    print(event["change"], event["path"])  # "modified src/main.py"

Reconnection & Session Recovery

When the MCP server restarts:

  1. Shells: Their PTY metadata is loaded from the database and re-spawned. Background processes (like npm run dev) will still be running on the system; reconnecting to the shell picks up where you left off.

  2. Processes: Background processes are re-attached to if they're still alive (by PID lookup).

  3. Watches: Not persisted (ephemeral); will need to be recreated.

This design assumes you're running this in a long-lived container (Docker or systemd) and not losing the PID space.

Security

  • Workspace sandboxing: resolve_path() ensures all operations stay within WORKSPACE_ROOT. Symlinks are resolved and validated.
  • No command injection: Process commands are passed as strings to subprocess.Popen(..., shell=True), so be careful with user input. Consider restricting this tool in production.
  • No authentication: This server is designed for a trusted network (your local machine, or behind a VPN/Tailscale). Run it behind a reverse proxy with auth in production.

Performance

  • First-call startup: ~50ms (database init, shell spawn)
  • Shell execute: 5–100ms depending on command
  • File operations: <5ms (mostly I/O latency, not CPU)
  • Search: 50–500ms depending on repo size and pattern complexity
  • Watch poll: 0ms if no changes, else <50ms to report changes

Testing

Run the workspace module smoke test:

export WORKSPACE_ROOT=/tmp/fake_workspace
python test_workspace_manual.py

This tests sandboxing, file I/O, patching, searching, tree walking, and watching.

TODO / Future

  • [ ] LSP diagnostics integration (pull errors from code-server's language servers)
  • [ ] VS Code Tasks runner
  • [ ] Port detection (surface forwarded ports from code-server)
  • [ ] Editor state (which files are open, cursor position)
  • [ ] Git wrappers (optional; can be used via shells)
  • [ ] Docker wrappers (optional; can be used via shells)
  • [ ] More comprehensive logging and telemetry
  • [ ] Pytest suite (currently only manual smoke tests)

Contributing

This is a single-developer project. If you'd like to extend it:

  1. Add new tools in the appropriate module (workspace/, terminal/, or a new one).
  2. Register them in app.py with @mcp.tool().
  3. Update this README.

Built for Claude on code-server. Not affiliated with Anthropic or Coder.

Recommended Servers

playwright-mcp

playwright-mcp

A Model Context Protocol server that enables LLMs to interact with web pages through structured accessibility snapshots without requiring vision models or screenshots.

Official
Featured
TypeScript
Magic Component Platform (MCP)

Magic Component Platform (MCP)

An AI-powered tool that generates modern UI components from natural language descriptions, integrating with popular IDEs to streamline UI development workflow.

Official
Featured
Local
TypeScript
Audiense Insights MCP Server

Audiense Insights MCP Server

Enables interaction with Audiense Insights accounts via the Model Context Protocol, facilitating the extraction and analysis of marketing insights and audience data including demographics, behavior, and influencer engagement.

Official
Featured
Local
TypeScript
VeyraX MCP

VeyraX MCP

Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.

Official
Featured
Local
graphlit-mcp-server

graphlit-mcp-server

The Model Context Protocol (MCP) Server enables integration between MCP clients and the Graphlit service. Ingest anything from Slack to Gmail to podcast feeds, in addition to web crawling, into a Graphlit project - and then retrieve relevant contents from the MCP client.

Official
Featured
TypeScript
Kagi MCP Server

Kagi MCP Server

An MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.

Official
Featured
Python
E2B

E2B

Using MCP to run code via e2b.

Official
Featured
Neon Database

Neon Database

MCP server for interacting with Neon Management API and databases

Official
Featured
Exa Search

Exa Search

A Model Context Protocol (MCP) server lets AI assistants like Claude use the Exa AI Search API for web searches. This setup allows AI models to get real-time web information in a safe and controlled way.

Official
Featured
Qdrant Server

Qdrant Server

This repository is an example of how to create a MCP server for Qdrant, a vector search engine.

Official
Featured