Beyond the
chat box.

An assistant is useful until the work leaves the chat. A setup window appears. A button needs a click. A screen must be checked. The words are done, but the task is not.

Picture asking for research, a draft, or a code fix. The assistant can prepare the answer, but a window still needs a click or the screen still needs a check. You become its hands at the exact moment the work matters.

The problem

ruOS is a full Linux desktop on a Google Cloud machine. People can view it through a browser, iPad viewer, or native Mac viewer. An assistant can enter through a separate secure login and operate that same desktop.

The public project supplies the controls and add-ons. You bring a running Linux desktop. It has real windows and apps, like a computer under your desk.

The big idea

An assistant can press a button, but a click alone does not tell it what happened. A fresh screen picture lets it choose the next step.

The same controls work across desktop apps: see, click, type, then see again. The assistant still has to judge what to do.

The aha

See the result before deciding what comes next.

Two paths reach the same Linux desktop: a viewer for you, and a remote login for the assistant.

The assistant starts ruos-mcp over SSH (an encrypted remote login). This Rust program exposes 16 tools for screen, mouse, keyboard, shell, and system tasks.

ruos-mcp adds no listening network socket. The SSH account can run unrestricted commands; trust that account.

The public repo contains control code and skills. Hosted signup and separate customer desktops remain roadmap work.

System tools need a separate local executor. Its display-resolution endpoint is proposed. Read the source and limits.

Architecture

Data flow

These are the paths the repo documents. The public control server's captured handshake proves its 16-tool surface; a successful remote graphical task still depends on a reachable desktop and its local tools.

In the real world

Start with a local check. You need Git, Rust with Cargo, and Bash or Zsh. This proves the control program runs; connecting a live Linux desktop is a separate step.

git clone \
  https://github.com/ruvnet/ruos
cd ruos/mcp
cargo build --release

init='{"jsonrpc":"2.0",'
init+='"id":1,'
init+='"method":"initialize",'
init+='"params":{'
init+='"protocolVersion":'
init+='"2025-06-18"}}'

list='{"jsonrpc":"2.0",'
list+='"id":2,'
list+='"method":"tools/list"}'

printf '%s\n' "$init" "$list" |
  ./target/release/ruos-mcp

1. Observed local result Recorded on 18 September 2026: server ruos-mcp, version 0.1.0, and 16 tools returned. These are fields from the actual replies. Remote screen control is a separate test.
2. Bring a Linux desktop. Remote screen control needs a running graphical session, xdotool, and a screenshot utility. The public repo does not provision the complete ruOS desktop for you.
3. Connect through your own account. Use the documented remote-login setup. Adjust the display-session settings for your machine. This account can run unrestricted shell commands.
4. Ask for one screenshot. Seeing an image from your own remote desktop is the first end-to-end check. We have not performed that remote check for this explainer.
5. Explore the rest. The tool reference explains each dependency. The skills guide covers teams of agents, memory, and learning.

Keep the guide and its sources together. Read the primer yourself, or let your assistant search the same source material.