PiloTY

PiloTY

PiloTY is an MCP server that provides AI agents with a persistent, interactive terminal, enabling long-running commands, log monitoring, and stateful shell interactions across tool calls.

Category
访问服务器

README

<p align="center"> <img src="assets/logo.png" alt="PiloTY logo" width="220" /> </p>

PiloTY

PiloTY (PTY for your AI Copilot) is an MCP server that gives an agent a persistent, interactive terminal.

If you have used Claude Code / Codex to run shell commands, you have probably hit the same wall: tool calls tend to be stateless. Each call starts "fresh", so environment variables disappear, interactive programs cannot be driven reliably, and long-running processes get cut off or orphaned while the agent is thinking.

PiloTY exists to make the agent's terminal behave more like a human's: start something in a real terminal, come back later, and keep going.

Warning: PiloTY exposes unrestricted terminal access. Treat it like giving the agent your keyboard.

What it enables

  • Long-running commands: builds, installs, migrations, test suites. Start once, check output later.
  • Log monitoring: tail -f, journalctl -f, kubectl logs -f, CI logs, service restarts.
  • "Vibe debugging": keep a REPL/debugger open while the agent reads code and tries ideas (python, ipython, pdb).
  • Privileged operations: handle interactive password prompts (sudo, SSH passwords, key passphrases).
  • SSH-based devops: keep a remote login session alive across tool calls; run remote commands in the same shell.
  • Terminal UIs: less, man, top, vim can work, but cursor-heavy programs often require screen snapshots instead of plain text output.

Quickstart

PiloTY is meant to be launched by an MCP client over stdio.

Add it to Codex CLI as an MCP server:

codex mcp add piloty -- uvx --from git+https://github.com/yiwenlu66/PiloTY.git piloty

If you prefer SSH-based Git fetch:

codex mcp add piloty -- uvx --from git+ssh://git@github.com/yiwenlu66/PiloTY.git piloty

If you already have a local clone:

codex mcp add piloty -- uv --directory /path/to/PiloTY run piloty

Run the server command directly (without adding it to an MCP client):

uvx --from git+https://github.com/yiwenlu66/PiloTY.git piloty

Mental model

One session is one real interactive terminal that stays alive across tool calls.

  • State persists: cwd, environment variables, foreground process, remote SSH connection, REPL/debugger state.
  • PiloTY tracks both the raw output stream and a rendered screen/scrollback view.

PiloTY keeps two representations:

  • output: incremental text stream (optionally ANSI-stripped)
  • Rendered screen/scrollback: what a human would see in a terminal

Public MCP results separate call outcome from terminal interpretation:

  • outcome: success, deadline_exceeded, eof, error, invalid_session, or terminated
  • terminal_state: best-effort rendered-state classification after the call (running, ready, password, confirm, repl, editor, pager, unknown)

Sessions are addressed by a session_id string. Reusing the same id is what keeps state.

Integration notes (for MCP integrators)

MCP does not expose a standard "client cwd" field, so the first step is always to create a session with an explicit working directory, then reuse the same session_id for subsequent calls.

Typical agent workflow:

  • Create a session (explicit cwd) and reuse the same session_id.
  • Use send_line to submit a newline-terminated command, send_text for raw bytes, and send_control / send_signal for interrupts.
  • Use wait_for_output for temporal PTY output waiting, wait_for_regex for content-based waits, and wait_for_shell_prompt after ssh or similar login flows.
  • Use snapshot_screen / snapshot_scrollback when layout matters. Snapshot tools are passive and do not ingest fresh PTY bytes.
  • If prompt detection is wrong, configure a custom shell-prompt regex.
  • Use send_password for secret entry; terminate the session when done.

For exact tool names, arguments, and return fields, use your MCP client's tool schema or read piloty/mcp_server.py.

Limitations

  • deadline_s is a wall-clock budget. On send/wait tools, it is not "process completion time".
  • Drain-based tools (send_line, send_text, send_control, send_password, send_signal, wait_for_output) stop after the server quiescence policy (PILOTY_QUIESCENCE_MS, default 1000) or when deadline_s expires.
  • wait_for_output can return partial output with outcome=deadline_exceeded if output started but the PTY never went quiet before the deadline.
  • wait_for_regex first checks already-rendered scrollback, then waits on new PTY bytes.
  • wait_for_shell_prompt consumes PTY output while it waits and returns the consumed bytes in output.
  • Terminal-state detection is best-effort and can be wrong (especially for custom prompts and cursor-heavy TUIs).
  • Plain text output can be misleading for full-screen programs; use screen snapshots when layout matters.
  • send_password() suppresses transcript logging and terminal echo for that send. It does not prevent other prompts/programs from echoing secrets later.
  • Quiescence-based output collection can be confused by programs that print periodic noise. Tune with PILOTY_QUIESCENCE_MS (default 1000).

Logs

Each server instance writes session logs under ~/.piloty/:

  • ~/.piloty/servers/<server-instance-id>/sessions/<session-id>/transcript.log: raw PTY bytes (combined stdout/stderr)
  • ~/.piloty/servers/<server-instance-id>/sessions/<session-id>/commands.log: inputs sent (best-effort)
  • ~/.piloty/servers/<server-instance-id>/sessions/<session-id>/interaction.log: inputs plus captured output (best-effort)
  • ~/.piloty/servers/<server-instance-id>/sessions/<session-id>/session.json: metadata snapshot
  • ~/.piloty/active/<server-instance-id>/<session-id>: symlink to the current session directory (when symlinks are supported)

Server logs default to /tmp/piloty.log.

tools/session_viewer.py can inspect sessions:

python tools/session_viewer.py list
python tools/session_viewer.py info <server-instance-id>/<session-id>
python tools/session_viewer.py tail -f <server-instance-id>/<session-id>

Development

Repository layout:

piloty/
  core.py        # PTY + terminal renderer + session logs
  mcp_server.py  # MCP tools + state inference
tests/
tools/
  pty_playground.py
  session_viewer.py

Run tests:

python -m pytest -q

License: Apache License 2.0, see LICENSE.

推荐服务器

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 模型以安全和受控的方式获取实时的网络信息。

官方
精选