clum

> clum — safe, reliable remote terminals for AI agents. (Renamed from yunying in 0.10.0; lineage: agent-ops → yunying → clum.)

> Secure infrastructure for AI agents and human operators managing Linux hosts — persistent terminal sessions powered by rmux, full-chain audit logging, MCP-native interface for AI clients + CLI PTY passthrough for humans, with file transfer, port forwarding, and multi-host orchestration.

中文文档

Why clum?

AI agents have evolved from "generating commands for humans" to autonomously operating terminals — deploying services, diagnosing failures, running long builds and training jobs, all without human intervention. But traditional terminal tools (SSH, tmux) were designed for human interaction, not programmatic API calls. clum is built on rmux, turning terminal sessions from a human interface into a programmable resource for both AI agents (via MCP) and human operators (via CLI PTY passthrough), with three production-grade layers on top.

Three problems stand between agent prototypes and production deployment, and existing tools (plain SSH MCP servers, basic tmux wrappers) largely ignore them:

• Reliability: Plain SSH drops running processes on disconnect — long-running tasks fail mid-flight. Traditional tmux automation relies on send-keys + sleep + grep, where any timing drift breaks the workflow.
• Auditability: When AI operates servers in production, you must trace who did what, when, on which machine, and with what result. Most SSH tools lack built-in audit capabilities entirely.
• Security boundary: Handing SSH keys directly to an AI client is a massive attack surface. clum uses Bridge proxy + Token auth + TLS encryption to confine server access to the target host — the client side (both MCP and CLI) never holds server credentials.

The three layers: Protocol layer (MCP standard interface for AI clients + CLI PTY passthrough for human operators), Management layer (multi-host registry, group/tag filtering, broadcast operations), and Compliance layer (structured SQLite audit trail covering both MCP and CLI operations, ready for operational traceability). Together they fill the infrastructure gap between agent prototypes and production readiness.

Where does it fit?

clum provides secure, reliable, auditable remote access to Linux hosts — terminal sessions, file transfer, port forwarding, and operation audit. It's not a replacement for SSH (transport layer), Ansible (configuration management), or tmux (terminal multiplexer). It's a new category: a remote operations platform that turns terminal sessions into programmable resources for both AI agents and humans.

clum doesn't care what runs inside the terminal — raw shell commands, Ansible playbooks, build scripts, or interactive debugging. It provides the persistent session + audit trail + multi-host operations, and you bring the tools.

A few patterns:```

Pattern 1: AI reads system state, makes decisions, executes fixes

AI Agent (via MCP)
→ exec: cat /proc/loadavg && df -h # read state
→ AI reasons: "disk full on /var/log"
→ exec: du -sh /var/log/* | sort -rh | head # diagnose
→ exec: journalctl --vacuum-size=500M # fix
→ audit trail: every step recorded in SQLite

Pattern 2: Human investigates via CLI while AI assists

Human (via CLI PTY passthrough)
→ clum-cli term tf01 # same session AI was working in
→ vim /etc/nginx/nginx.conf # human edits in familiar tools
AI Agent (via MCP)
→ exec: nginx -t && systemctl reload nginx # AI validates & applies

Pattern 3: Multi-host batch operations

AI (via MCP)
→ host_filter tags=["web"] # select target hosts
→ batch_exec: systemctl status nginx # check all web servers
→ batch_upload: nginx.conf → /etc/nginx/ # push config to all
→ batch_exec: nginx -s reload # reload all at once

**Use cases:**
- **Incident response**: AI or human jumps into a live session, reads system state, diagnoses root cause, and executes repairs — all within the same persistent terminal
- **Ad-hoc operations**: Quick one-off commands across multiple hosts (`batch_exec`), file transfers, port forwarding — no Playbook needed
- **Interactive debugging**: Persistent sessions for builds, long-running task monitoring, or interactive troubleshooting via both MCP (AI) and CLI PTY passthrough (human)
- **Remote development**: `clum-cli term devbox` — work on a remote machine with your familiar terminal environment, with AI assistance one keystroke away (Ctrl+G)
- **Compliance auditing**: Full-chain audit trail covering both AI and human operations on every host, queryable via `clum-mcp audit query`

## Architecture```mermaid
graph LR
    A[AI Client<br/>opencode/Claude/Cursor] <-->|HTTP :9788<br/>MCP Streamable HTTP| S[Central MCP Server<br/>clum-mcp --mode http]
    H[Human] <-->|QUIC :9788<br/>PTY / upload / forward| S
    S <-->|QUIC :9788<br/>reverse registration| C1[rmux-bridge<br/>host-1]
    S <-->|QUIC :9788| C2[rmux-bridge<br/>host-2]
    S <-->|QUIC :9788| C3[rmux-bridge<br/>host-N]
    C1 <-->|Unix Socket| D1[RMUX daemon]
    C2 <-->|Unix Socket| D2[RMUX daemon]
    C3 <-->|Unix Socket| D3[RMUX daemon]

• clum-mcp (Central Server) — Central MCP Server: HTTP :9788 for AI clients (MCP protocol) + QUIC :9788 for Bridge registration and CLI data plane. Provides 68 tools, centralized audit, API Key auth, and static file serving.
• clum-cli — CLI for humans: PTY passthrough (term), file transfer (push/pull — files or directories, chunked streaming with SHA-256; push supports --exclude globs for directories), port forwarding (forward — auto-reconnects on network loss, --give-up-after), session listing (list), recording playback (replay). Built-in AI chat panel (Ctrl+G). Congestion control default auto: BBR on private targets, CUBIC on public targets (loss-adaptive, avoids disconnects at full bandwidth); override with --cc bbr · cubic · auto (or CLUM_CC env var).
• rmux-bridge — Agent deployed on each Linux host. Reverse-connects to the Central Server, handles tool execution, file I/O, PTY sessions, and recording push.
• RMUX daemon — Terminal multiplexer on each Linux host (rmux-based).

Deployment model:

> 💡 New bridges deploy with one command (after the server's releases/ assets are staged — see below): curl -fsSLk -H "Authorization: Bearer " https://SERVER:9788/releases/install.sh | BRIDGE_TOKEN=xxx SERVER_ADDR=SERVER:9788 sh
>
> ` andBRIDGE_TOKEN=xxxare the **same** bridge token (fromclum-mcp bridge add) — the install script uses it both for the download header and for registration. > > ⚠️/releases/*is served from/releases/, and no deployment script stages those files. Putdeploy/install.sh,certs/ca.crtand the bridge binary (namedrmux-bridge-linux-) under/releases/` first — otherwise the URL returns nothing.

> 💡 During deployment, the bridge auto-detects the RMUX socket path — no manual configuration needed.

Features

Feature · Description
Interactive terminal · clum-cli term — transparent raw pane passthrough by default (no rmux UI layer, ssh-like); --mux opts into the full rmux attach-session UI (status bar + Ctrl+B prefix). Auto-creates the session if it doesn't exist. Built-in AI chat panel (Ctrl+G) with real-time SSE streaming; supports vim/htop/TUI
Session management · Create/destroy/list sessions, multi-pane splits, window layouts
Command execution · exec one-shot execution (sentinel detection + exit code, full scrollback capture for large outputs, auto-reconnect on connection drop), interactive programs via send_keys + capture_pane
Output waiting · wait_for_text for terminal text, wait_exit for process exit, wait_stable for output quiescence, wait_for_bytes for raw byte sequences
File transfer · Upload/download over QUIC (clum-cli and MCP tools), recursive directory transfer with concurrency and --exclude globs, chunked streaming with SHA-256 verification
Port forwarding · Local port forwarding forwards through QUIC to access remote internal services
Multi-host orchestration · Host registry with group/tag/label filtering, broadcast_keys for multi-pane
Audit logging · SQLite audit logs + bridge-side PTY recording (asciinema v2 content, encrypted at rest via X25519 + AES-256-GCM) + event log + push/periodic sync + clum-cli replay playback
Terminal state awareness · capture_pane, exec, wait_for_text, wait_stable, pane_info return terminal_state (ready/running/editor/pager/password/confirm/repl/unknown) and cursor position, so AI agents know what the terminal is currently doing
Exec safety check · exec refuses execution when terminal is not in ready state (e.g., inside vim, less, password prompt), returning refused: true with actionable guidance to prevent command injection; state-detection failures also refuse (fail-closed)
Command rule engine · permissive (default) / strict policy before execution (clum-command-kb). Quote-aware normalization splits &&/;/\ ·/redirects/command-substitution and strips sudo/env/timeout wrappers; compound commands take the strictest verdict. In permissive mode anything not matching an explicit deny runs; the destructive list lives in config/command-rules.toml (rm critical paths, dd block devices, mkfs/partitioning, shutdown, firewall flush, kill init, interpreter/xargs wrappers). No human approval channel. Policy keys on tool × program × argv regex × host group × caller group. The 1,607-entry knowledge base is retained as legacy reference (it no longer affects permissive verdicts); its read_only marks still serve command:read

AI Chat Panel Keybindings

Inside the AI panel (activated via Ctrl+G):

The message view auto-scrolls to the latest output (follow mode) while the AI streams; scrolling up pauses it for reviewing history, and scrolling back to the bottom resumes it. While waiting for a response, an animated spinner with elapsed seconds is shown.

The AI panel starts an opencode serve process on first use (port 14096). It persists across panel open/close cycles and is cleaned up when the CLI exits. Use --opencode-dir to control the working directory (default: current directory).

PTY passthrough mode forwards raw terminal bytes — mouse events work when the remote application enables mouse mode (e.g., vim, htop).

Quick Start

Build```bash

Native build (macOS dev)

cargo build -p clum-mcp --release
cargo build -p clum-cli --release

Cross-compile bridge + MCP server for Linux x86_64 (static)

just release-linux

### Deploy```bash
# Step 1: Deploy rmux daemon (on remote host)
bash deploy/install-daemon.sh root@<your-bridge-ip>

# Step 2: Compile & deploy bridge (one-shot)
just release-linux
BRIDGE_TOKEN="<your-token>" CLUM_SERVER_ADDR=SERVER:9788 just deploy-bridge host=root@<your-bridge-ip>

Host Registry

Create config/hosts.yaml (see config/hosts.example.yaml):```yaml
hosts:
# Enrolled mode (recommended) — bridge reverse-registers, no addr/token needed:
- name: prod-web-01
group: production
tags: [web, nginx]
labels:
dc: shanghai

# Direct mode (fallback) — connect to bridge directly:
- name: legacy-host
bridge_addr: 10.0.1.10:9778
bridge_token: "your-token-here"

> 💡 **Hot-reload**: After editing `hosts.yaml`, reload without restarting — either call the `reload_config` MCP tool or send `kill -HUP ` to the MCP server process.

### MCP Client Config

**Central Server mode** (recommended — one URL + API Key):```json
{
  "mcp": {
    "clum": {
      "type": "remote",
      "url": "https://SERVER:9788/mcp",
      "headers": { "Authorization": "Bearer yk_name_..." }
    }
  }
}

Local stdio mode (no central server, direct connections):```json
{
"mcp": {
"clum": {
"type": "local",
"command": ["/path/to/clum-mcp"],
"args": ["--ca-cert", "/path/to/ca.crt", "--hosts-file", "/path/to/hosts.yaml"],
"enabled": true
}
}
}

> Use `ca.crt` for remote deployments; `bridge.crt` works for local self-signed testing.

### Server Management```bash
# API Key management
clum-mcp agent add <name> (--group <g> | --admin)  # Create key (--admin = superadmin, --group = restricted)
clum-mcp agent list             # List all keys (shows GROUP column)
clum-mcp agent rotate <name>    # Rotate a key (inherits group)
clum-mcp agent revoke <name>    # Revoke a key

# Group isolation: grouped keys can only access hosts in their group.
# host_list/audit_query/recordings auto-filter; reload_config/host_set_meta blocked.

# Role / capability policy (P0): default deny; existing keys migrate to legacy roles
clum-mcp role list
clum-mcp role grant operator --group dev --actions host:read,session:attach,command:exec
# --require-approval only tightens allow -> ask. Under the default `permissive`
# policy ask still executes; it blocks only under `command_policy: strict`.
# There is no human approval channel.
clum-mcp role grant operator --group prod --actions command:exec
clum-mcp role bind --key agent-dev --role operator
clum-mcp policy explain --key agent-dev --tool exec --host tf001

# Bridge enrollment (dynamic registration, no hosts.yaml edit needed)
clum-mcp bridge add <hostname> --tags <t1,t2> [--group <g>]
clum-mcp bridge list
clum-mcp bridge remove <hostname>
clum-mcp bridge join <hostname>   # Generate a new join token (offline recovery)

> When no API keys exist yet (fresh install), the server runs in bootstrap mode: loopback connections act as superadmin (console access on the server host); non-loopback requests are rejected until the first agent add creates a key.

Security

Production: Run your own CA, issue per-bridge certificates, MCP server holds only the CA root.

Built-in protections:
- Path traversal prevention: File upload/download rejects paths containing ..
- Tunnel target whitelist: Optional allowed_forward_targets in hosts.yaml restricts port forwarding targets (glob patterns) — applies to hosts defined in hosts.yaml; dynamically-enrolled bridges without a matching entry have no whitelist (all targets allowed)
- Exec safety check: exec refuses execution when terminal is not in ready state (prevents command injection into vim/less/password prompts); detection failures also refuse (fail-closed)
- Role/capability layer (P0): each API key is an independent principal, evaluated as role → grant (resource selector × capability) before the command rule engine. Default deny; existing keys migrate to legacy roles (behaviour unchanged); admin is not intended for the agent runtime; policy lives in the audit DB and every role mutation is sealed into the audit hash chain. command:read permits only commands explicitly marked read-only (whitelist, default deny, sudo is not read-only). CLI relays (term/forward/push/pull/list) are checked by purpose at connection establishment — cross-group or ungranted relays are rejected; replay uses HTTPS /recordings and is checked with the same host + recording:read rule
- Command rule engine: every command-carrying tool call (exec, shell_command, batch_exec, send_keys, send_text, batch_send_keys, broadcast_keys, respawn_pane, split_pane_with, cmd_escape) is normalized and judged server-side — an AI client's own permission config can only be stricter, never looser. In permissive mode anything not matching an explicit deny runs; in strict mode ask fails closed. A destructive-rule hit returns COMMAND_DENIED. Verdicts are deterministic and replayable, and every denial is sealed into the audit hash chain. These rules are a guardrail against mistakes, not a security boundary
- Sensitive input redaction: Inputs sent while the terminal is in password state are auto-redacted in the audit log ([REDACTED:N bytes], server-enforced, no opt-out); the sensitive flag on input tools forces redaction for tokens/2FA codes

Audit```bash

Recent operations

clum-mcp audit query --format table

Commands on specific host

clum-mcp audit query --host tf01 --action exec --since 2026-06-01

Statistics

clum-mcp audit stats

Manual cleanup

clum-mcp audit cleanup --older-than 30

Verify hash-chain integrity (Chain head can be copied to an external

system for offline comparison — see INVARIANTS.md §8)

clum-mcp audit verify

Chain check: OK / Hashed events: 12345 / Chain head: <hex64>

Audit data stored at `~/.clum/audit.db`, retained 90 days, 500 MB soft cap (cleanup prunes the oldest events; file size may transiently exceed the cap). Every event is sealed into a forward hash chain (`entry_hash = SHA256(prev_hash ‖ payload)`); `audit verify` recomputes the full chain and exits non-zero on the first tampered or missing record.

## Knowledge Base (Design Concept)

clum produces detailed audit trails for every operation, but raw audit logs answer "what happened" — not "why it happened" or "how to fix it next time." This section outlines a design philosophy for turning operational experience into a shared knowledge base. The implementation is deliberately left to users, because **knowledge base backends are a matter of team infrastructure preference, not tooling prescription**.

### The Problem

After an AI-driven troubleshooting session:

- **Knowledge stays local**: the diagnosis, root cause, and fix live only in the chat transcript.
- **No sharing**: other team members can't search for similar past incidents.
- **Manual overhead**: writing up a postmortem or wiki entry requires remembering context days later.

### Three-Layer Design```
┌─────────────┐    session activity    ┌──────────────────┐
│  clum  │ ─── audit events ────→ │  Knowledge        │
│  (MCP)      │    (SQLite)            │  Extraction       │
└─────────────┘                        │  (AI review)      │
                                       └────────┬─────────┘
                                                │ structured entry
                                                ▼
                                       ┌──────────────────┐
                                       │  Output Adapter   │
                                       │  (user-defined)   │
                                       └───┬──┬──┬──┬────┘
                                           │  │  │  │
                                      ONES │ wiki GitBook ...
                                           │
                                     curl / git / webhook

1. Collection (built-in)

The existing audit system records every MCP tool invocation and CLI operation — exec, capture_pane, session_create, term, etc. — with timestamps, host, success/failure, and error messages. No changes needed.

2. Extraction (AI-driven)

When the user explicitly triggers "save this session as knowledge," the AI reviews the full conversation history plus the audit trail for that session. It extracts:

The output is a structured JSON entry, not a Markdown file — so the output adapter can transform it to any format.

3. Output (user-defined)

We intentionally do NOT build platform-specific integrations. Instead, users define a sink — a script, command, or webhook that receives the knowledge entry via stdin (JSON). Examples:```bash

~/.clum/sink.sh — push to ONES wiki

curl -X POST "https://ones.example.com/wiki/api" \
-H "Authorization: Bearer $TOKEN" \
-d "$(cat)"
``````bash

Push to a git-based knowledge repo

echo "$(cat)" >> knowledge.jsonl && git commit -am "add troubleshooting entry"

### Design Principles

- **User decides when**: knowledge extraction is explicitly triggered, not automatic — avoids noise entries from incomplete sessions.
- **User decides where**: no platform lock-in. The sink is whatever CLI/API your team already uses.
- **User reviews before publishing**: AI-generated entries should be reviewed and edited before being pushed to shared storage.
- **JSON as interchange**: structured data can be transformed to Markdown, API payloads, database rows, etc.

This design keeps clum focused on operations while enabling teams to build their own knowledge pipelines on top of the audit data it already generates.

## Tools

68 MCP tools covering the full terminal lifecycle, plus `audit query/stats/cleanup` CLI subcommands for human operators:

| Category | Tools |
|----------|-------|
| Host | `host_list`, `host_filter`, `host_set_meta`, `reload_config` |
| Session | `session_create`, `session_list`, `session_attach`, `kill_session` |
| Input | `send_keys`, `send_text`, `broadcast_keys` |
| Output | `capture_pane`, `capture_region`, `wait_for_text`, `wait_for_bytes`, `find_pane_text`, `find_text_all`, `stream_pane` |
| Execution | `exec`, `wait_exit`, `wait_stable`, `collect_until_exit`, `shell_command`, `respawn_pane`, `cmd_escape` |
| Pane | `split_pane`, `split_pane_with`, `break_pane`, `join_pane`, `swap_pane`, `resize_pane`, `set_pane_title`, `get_pane_title`, `clear_history`, `close_pane`, `pane_info`, `pane_exists` |
| Window | `split_window`, `close_window`, `rename_window`, `resize_window`, `select_window`, `select_layout`, `window_info`, `list_window_panes` |
| Discovery | `find_panes`, `find_sessions`, `get_pane_by_title`, `host_capabilities` |
| Buffer | `list_buffers`, `paste_buffer`, `delete_buffer` |
| File | `file_upload`, `file_download` |
| Batch | `batch_exec`, `batch_send_keys`, `batch_upload`, `batch_download` |
| Tunnel | `forward_create`, `forward_list`, `forward_close` |
| Deploy | `deploy_bridge` |
| Audit | `audit_query`, `query_bridge_audit`, `list_recordings`, `get_recording`, `search_recordings` |
| System | `clum_usage_rules` |

> 💡 `stream_pane` is ideal for real-time output monitoring of long-running commands (blocking read, incremental return), replacing capture_pane polling.

Full docs: clum-docs/TOOLS.md

## Performance

| Optimization | Before | After | Gain |
|--------------|--------|-------|------|
| QUIC BBR congestion control + 16MB flow window | 200MB upload: 60.4s | 28.1s | +53% |
| Receiver-side SHA256 (eliminate double-read) | 200MB download: 63.5s | 21.8s | +192% |
| 1MB copy buffer (was 8KB default) | syscall count: N | N/128 | 128x fewer |
| Bridge deploy (fire-and-forget restart) | 47s | 4s | -91% |

Steady-state throughput: **82 Mbps** (1GB file, 82% link utilization on 100 Mbps link).

Key design choices:
- **BBR for private, CUBIC for public**: BBR's model-based rate control tolerates packet loss without drastic window reduction (used on private-network targets); CUBIC backs off on loss for public targets. Since v0.15.0 the default is `auto` — see loss-adaptive below.
- **Loss-adaptive congestion control**: `auto` mode picks BBR for private-network targets (max throughput) and CUBIC for public targets (backs off on loss like TCP — public links at full bandwidth no longer drop the connection). Override per component: `clum-cli --cc` (or `CLUM_CC` env), server `CLUM_CC`, bridge `BRIDGE_CC`.
- **Receiver computes hash**: Sender streams data in one pass; receiver calculates SHA256 inline — halves disk I/O on the sending side
- **Unified 1MB buffer**: `COPY_BUF_SIZE = 1MB` is shared by MCP, Bridge, and the CLI port-forward path — aligned to avoid cross-boundary buffering

## Development```bash
just check       # cargo check --workspace
just test        # cargo test --workspace
just fmt         # cargo fmt --all
just lint        # cargo clippy --workspace -- -D warnings
just build       # cargo build --workspace
just release-linux  # cross-compile Linux x86_64 musl

Tech Stack

• Language: Rust stable (edition 2021)
• Async runtime: tokio
• TLS: rustls (no OpenSSL dependency)
• Terminal: rmux-sdk
• Audit storage: rusqlite (bundled SQLite)
• MCP transport: stdio + Streamable HTTP (rmcp v3, JSON-RPC 2.0)

Docs

• Tool Reference — 68 MCP tools with parameters and return values
• Deployment Guide — Architecture, build, deploy, operations, security
• Terminal State Design — Terminal state awareness heuristic engine
• Contributing
• Security Policy
• Changelog

License

MIT. The command knowledge base embeds data from third-party projects; see
THIRD_PARTY_NOTICES.md for attribution and licenses.