exec-mcp

A strict TypeScript Node.js gateway with no runtime npm dependencies that gives trusted MCP clients bounded remote command execution and file transfer over SSH.

exec-mcp deliberately stays small: it validates paths and resource limits, runs a non-interactive remote shell, streams or returns bounded output, and exposes execution lifecycle controls. Higher-level behavior remains in tools already installed on the remote host.

Features

• MCP Streamable HTTP and an HTTP/SSE execution endpoint.

• Configurable command timeout, output limit, concurrency limit, and bounded tail buffers.

• Remote working-directory allowlist with realpath and symlink-escape checks.

• ChatGPT-native bidirectional artifact transfer using file references, binary SSH streaming, SHA-256 verification, and atomic remote commits.

• Embedded-resource export that materializes verified remote files into ChatGPT without model-authored Base64.

• Unified Exec Job Manager with synchronous exec, asynchronous start_exec, queued admission, recent status lookup, and idempotent cancellation.

• Incremental retained job logs with independent stdout/stderr cursors and bounded long-polling.

• One authoritative remote supervisor for process-group cleanup, command deadlines, cancellation, termination escalation, and final execution results.

• Secret-pattern redaction for streamed output and retained tails.

• Prometheus-compatible metrics and health endpoints.

• Execution-capacity gauges and duration histograms for latency percentiles.

• Strict TypeScript source compiled to JavaScript for production.

• No runtime npm dependencies.

Related MCP server: SSH Real MCP Server

MCP tools

The control-plane tools are operator-wide. They assume one trusted tenant and are intentionally available even when command capacity is full.

Explicit task context

MCP protocol sessions are not treated as ChatGPT conversation identity. Create one task context for each independent conversation or logical workstream. Reuse its task_handle for all exec/start_exec calls in that workstream, and do not reuse a handle across unrelated tasks.

exec and start_exec require a server-issued handle at the MCP schema and runtime-validation layers. An unknown or invented handle is rejected with unknown_task_handle, which instructs the caller to run begin_task. get_exec_status and cancel_exec need only exec_id; task ownership is already stored with the execution. The handle is correlation metadata only and grants no authorization. Task contexts are bounded and process-local, matching the existing Runtime/Job Manager retention model.

This follows the MCP explicit-handle pattern for carrying application state across otherwise stateless requests. It provides reliable Execution MCP grouping without pretending that the server knows ChatGPT's internal conversation ID.

Choosing exec vs start_exec

Use exec for short, deterministic commands when the next reasoning step needs the result immediately. A useful rule of thumb is roughly five seconds or less: pwd, ls, cat/grep, git status/git diff, kubectl get, and similar probes.

Use start_exec when runtime is uncertain, may exceed a few seconds, or useful work can continue in parallel. Typical examples are dependency installation, test suites, builds, image builds, scans, migrations, and long scripts. Keep the returned exec_id, continue independent work, and use get_exec_status at the synchronization point (optionally with bounded wait_seconds) rather than busy-polling immediately after submission.

Do not emulate background execution inside exec with nohup, disown, or shell &. Pass the real foreground command to start_exec so timeout, cancellation, status, retained logs, and remote process-group cleanup remain owned by the Job Manager. Use concise label values when several independent jobs run concurrently.

Quick start

Requirements

• Node.js 20 or newer, or Docker.

• An SSH-reachable remote host with /bin/sh and Python 3.

• A dedicated SSH key and a pinned known_hosts file.

Run with Docker

docker run --rm \
  --name exec-mcp \
  -p 127.0.0.1:8080:8080 \
  -p 127.0.0.1:9090:9090 \
  -e REMOTE_HOST=remote-host \
  -e REMOTE_USER=execmcp \
  -e REMOTE_KEY_PATH=/run/secrets/id_ed25519 \
  -e REMOTE_KNOWN_HOSTS_PATH=/run/secrets/known_hosts \
  -e REMOTE_STRICT_HOST_KEY_CHECKING=yes \
  -e ALLOWED_CWDS=/workspace,/tmp \
  -e DEFAULT_CWD=/workspace \
  -v "$PWD/id_ed25519:/run/secrets/id_ed25519:ro" \
  -v "$PWD/known_hosts:/run/secrets/known_hosts:ro" \
  ghcr.io/3011/exec-mcp:v0.7.0

The example binds only to loopback. Add authentication and TLS at the surrounding transport layer before making the service reachable from another machine.

Container tags follow the repository release model:

• vX.Y.Z is the versioned release tag; treat release tags as immutable by policy.

• sha-<short-commit> identifies an exact commit build; an image digest is the strongest immutable deployment reference.

• main tracks the latest successful default-branch build and should not be treated as an immutable production version.

Run from source

git clone https://github.com/3011/exec-mcp.git
cd exec-mcp
npm ci
npm run validate

REMOTE_HOST=remote-host \
REMOTE_USER=execmcp \
REMOTE_KEY_PATH="$HOME/.ssh/id_ed25519" \
REMOTE_KNOWN_HOSTS_PATH="$HOME/.ssh/known_hosts" \
REMOTE_STRICT_HOST_KEY_CHECKING=yes \
ALLOWED_CWDS=/workspace,/tmp \
DEFAULT_CWD=/workspace \
npm start

Interfaces

• GET /healthz

• GET /metrics

• GET /runtime read-only Runtime Console

• GET /runtime/api/* read-only runtime observation API

• POST /exec with Accept: text/event-stream

• POST /mcp for MCP Streamable HTTP / JSON-RPC

• Optional separate metrics listener on METRICS_PORT

Runtime Console

GET /runtime serves a dependency-free, read-only execution viewer from the main listener. It is intentionally not exposed by the optional METRICS_PORT listener and provides no run, retry, cancel, kill, or other mutation endpoint.

The console focuses on current execution state rather than historical metrics: running/queued jobs, capacity, last runtime activity, last output time, retained stdout/stderr, origin metadata, a bounded lifecycle trace, and small lifecycle timing diagnostics. Executions are grouped under explicit Task Contexts. Activity and output are deliberately separate signals: a job can remain alive and observable while producing no output. Quiet periods are never labeled as hung or stuck without proof.

Lifecycle timings and diagnostics are derived at query time from timestamps the Runtime Observer already records; they add no timers, background workers, database, or persistent state. The derived fields cover queue wait, local transport/runner launch, time to first output, runtime, termination, total duration, coarse phase/activity, and a conservative failure phase. transport_startup_ms describes local runner/transport launch only and does not claim that SSH handshake or remote process startup has completed.

Trace origin records only facts the server actually receives. An MCP transport session identifier may be shown, but it is explicitly not treated as a ChatGPT conversation identifier. MCP executions now carry a server-issued explicit task_handle created by begin_task; the Runtime Console groups executions by that handle and displays the optional task label. The handle is a logical correlation context, not proof of ChatGPT's internal conversation ID.

Runtime state, traces, and retained output remain bounded and process-local, matching the existing Job Manager lifecycle. The console uses the same externally authenticated network boundary as the main service; there is no separate built-in Runtime Console authentication layer.

MCP initialization

curl -fsS http://127.0.0.1:8080/mcp \
  -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"example-client","version":"1.0.0"}}}'

Execute a command

{
  "command": "git status --short",
  "shell": "sh",
  "cwd": "/workspace",
  "timeout_seconds": 120,
  "max_output_bytes": 5242880,
  "env": {
    "NO_COLOR": "1"
  },
  "label": "inspect repository status"
}

Every command must explicitly select shell: "sh" or shell: "bash". sh uses /bin/sh -c; bash uses /bin/bash -c for Bash-specific syntax. No default shell is applied, only these two interpreters are supported, and login/interactive shells are never used. The caller is intentionally allowed to supply arbitrary shell text; authorization must therefore happen before requests reach this service.

Output semantics

• /exec emits SSE lifecycle events.

• MCP tools/call returns bounded final text plus structured content; it does not stream live command events.

• The final execution summary is authoritative for exit code, signal, timeout, duration, byte counts, and truncation.

• Stderr output alone does not indicate failure. A non-zero exit code, signal, or timeout does.

• Once the forwarding limit is reached, output is still drained so the child process cannot block on a full pipe.

• Synchronous exec keeps bounded final stdout/stderr tails for compatibility.

• get_exec_status reads bounded retained Job Manager logs incrementally with independent stdout/stderr cursors. It also returns query-time timings and diagnostics derived from existing lifecycle timestamps so an agent can distinguish queue, launch, running, quiet, and termination phases without a separate tracing service. has_more_* means another retained page is available; *_log_truncated means older bytes were permanently discarded.

• Runtime timeout starts only when a queued job enters execution; queue waiting time does not consume timeout_seconds.

• V1 Job Manager state and retained logs are process-local; service restart does not recover prior queued or running records.

Cancellation boundary

Running executions use one SSH session to a remote Python supervisor. The supervisor is the authoritative owner of the command process group: it enforces the business timeout, receives cancellation requests over the same framed session, performs bounded SIGTERM-to-SIGKILL escalation, reaps the group, and returns the final execution reason. A small durable result journal is used only to recover that final fact if the primary SSH transport disappears before the result reaches exec-mcp. Queued jobs can still be cancelled before any process is spawned. If the remote final state cannot be authoritatively recovered, the execution circuit fails closed instead of claiming that termination succeeded.

Configuration

For all lifecycle and circuit-breaker settings, see DESIGN.md.

ChatGPT artifact transfer

Use import_chatgpt_file for files attached to or generated in the current ChatGPT conversation. The tool declares _meta["openai/fileParams"], so ChatGPT replaces the conversation-local file path with a temporary { download_url, file_id, mime_type?, file_name? } reference. exec-mcp downloads the binary bytes to a bounded local spool, computes SHA-256, streams the bytes over SSH, verifies the remote hash, and commits the destination atomically. Retried calls are idempotent when the existing destination has identical bytes.

Use export_remote_file for the reverse direction. It streams the remote file into a bounded local spool, verifies size and SHA-256, reads the verified bytes, and returns exactly one MCP embedded binary resource plus structured metadata (bytes, sha256, file_name, embedded=true, and delivery_mode=embedded_resource). A compatible ChatGPT host can materialize that resource as a real file in /mnt/data while preserving file_name.

Exports larger than ARTIFACT_EMBED_MAX_BYTES are rejected with file_too_large; the service deliberately provides no resource_link, public download URL, or large-file fallback. The embedded blob is Base64 at the MCP protocol layer, so the practical ceiling must account for Base64 expansion, JSON framing, tunnel limits, host materialization limits, and gateway memory. The hard maximum and default are 1.45 MB (1,450,000 bytes). This conservative ceiling is covered by backend boundary tests and intentionally leaves margin below the platform-sensitive range observed during ChatGPT host ingestion/materialization testing.

Secure MCP Tunnel carries the embedded bytes inside MCP JSON-RPC, so remote-to-ChatGPT export requires no public artifact ingress. Keep /mcp, /exec, /runtime, /runtime/api/*, /metrics, and /healthz private behind the authenticated transport.

Development

npm test             # strict build and regression tests
npm run build        # strict type-check and compile to dist/
npm run test:memory  # bounded-output and RSS smoke test
npm run validate     # canonical gate: build, tests, Runtime/HTTP/SSE, and memory smoke tests

Runtime source is organized by responsibility: server.ts for HTTP composition and lifecycle, mcp-handler.ts for JSON-RPC dispatch, exec-runner.ts for Job Manager admission/queue/status orchestration, remote-execution-session.ts for one remote execution session, remote-supervisor.ts for the authoritative remote process lifecycle, ssh-transport.ts for shared SSH transport primitives, artifact-transfer.ts for verified bidirectional file transfer, runtime-observer.ts for bounded execution observations/traces, runtime-console.ts for the read-only browser surface, and metrics.ts for Prometheus rendering.

CI runs the same npm run validate gate used for local release checks before building the container. The compiled Node test runner uses a bounded file-level concurrency of 4 to reduce timing contention in process/HTTP lifecycle tests. CodeQL and Dependabot configuration are included in the repository.

Documentation

• Design

• Operational runbook

• Threat model

• Security policy

• Contributing

• Changelog

Versioning

The project uses Semantic Versioning. The version in package.json, MCP serverInfo, Git tags, GitHub Releases, and published container tags must match. Historical internal architecture labels are not part of the public version scheme.

License

MIT