Skip to main content
Glama

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.

Related MCP server: pokeclaw

Installation

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.

F
license - not found
-
quality - not tested
C
maintenance

Maintenance

Maintainers
Response time
Release cycle
Releases (12mo)
Commit activity

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Servers

View all related MCP servers

Related MCP Connectors

  • MCP server for interacting with the Supabase platform

  • A MCP server built for developers enabling Git based project management with project and personal…

  • Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).

View all MCP Connectors

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yangkerrrr/CodeserverMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server