Hermes Desktop streams any bot screen live with takeover

Nous Research has shipped Bot Screen. Hermes Desktop now live-streams each Linux-gateway bot’s own Xfce desktop so you can watch computer-use and browser work, take over for logins, then hand control back.

On September 23, 2026, @NousResearch said you can watch agents work live as Hermes Desktop streams any bot’s screen or session in real time — a browser, a terminal, or a newly opened window — and take over anytime to type credentials, then hand control back.

The official docs pin the feature to a headless Linux gateway: a server, a cloud VM, or Hermes Cloud. macOS and Windows hosts already have a real display; the pane is not offered there. Each Hermes profile (“bot”) gets its own Xfce desktop. The bot’s computer_use tools and headed browser act on that screen. The desktop lives on the gateway, not on your laptop, so the bot keeps working after you close the app or power down.

Every profile has its own screen, browser profile, and cookies. Screens are work surfaces, not security boundaries. Bots share the host’s user account, files, and network.

Take over, then hand back

Open Screen from a bot’s Scheduled Jobs view, from Open Screen on the bot, or from the Sessions sidebar. The screen is off by default until you start it in the pane, run hermes computer-use screen start, or set bot_desktop.auto_start: true. Click Take over. The border turns red and your keyboard and mouse drive the bot’s desktop — a login, 2FA prompt, CAPTCHA, or payment. Click Hand back and the bot re-captures the screen before continuing. Closing the pane also hands control back.

A dropped connection is different. If the lid closes or Wi-Fi drops while you hold control, you keep the lease. The bot stays locked out of a screen you may be mid-login on until you reconnect and hand back. After a reload, Hand back (force) can clear a stuck human lease. Two viewers on one screen: the most recent Take over wins.

While a human holds control, computer_use and browser tools are refused with human_has_control, captures included. That is a tool-level fence, not OS isolation. The bot runs as the same user as its screen. Don’t type secrets into a bot you wouldn’t trust with them. When the bot hits a step it should not do itself, it says so in its reply and ends its turn. Taking over is always yours to start; a bot never holds a tool call open waiting for you.

The threat model is explicit

The screen’s RFB socket, the X display, the browser profile, and the control-lease file all belong to the gateway’s OS user. Any process running as that user — another bot on the same host, and the bot’s own terminal tool included — can reach them directly, bypassing the pane and the lease. Chromium’s DevTools port on loopback is reachable by any local user on the host. Running each bot as its own OS user is out of scope. If that isolation matters, or the host has untrusted local users, put the bots on separate hosts.

The WebSocket bridge caches its lease decision for up to 250 ms between re-reads of the lease file. The viewer’s single-use, 30-second display_ticket travels as a URL query parameter because noVNC cannot negotiate WebSocket subprotocols, so a reverse proxy’s access log may record an already-spent ticket.

Requirements and CLI

The gateway must run Linux, with TigerVNC’s Xvnc and the Xfce core components installed. Nothing installs them silently. Computer Use must be enabled for the bot. Before a screen starts, Hermes checks bot_desktop.min_free_memory_mb free (default 1536). Measured in the official image, plan on about 1.1–1.5 GB per open screen with a browser.

From a shell on the host:

hermes computer-use screen status
hermes computer-use screen start
hermes computer-use screen stop
hermes computer-use screen install

stop refuses while a human holds control unless you pass --force.

Read the Bot Screen docs for the install table, takeover flow, and threat model, then run hermes computer-use screen status on a Linux gateway.

Sources

• Nous Research on X
• Bot Screen — Hermes Agent docs