Live Desktop

What You Get

A hosted agent is a container somewhere. Most of the time you only ever meet it through chat, and the container is an abstraction. Live Desktop makes it concrete: you see a screen belonging to that container, and you can use it.

• A dock with launchers, so it behaves like a desktop rather than a demo.
• A terminal window, in the same filesystem your agent works in.
• A file manager, for the times a graphical tree beats ls.
• A browser launcher that brings the agent’s own browser in as a window, so you can watch a web task without leaving the desktop.
• GUI applications the agent opens, visible while they run.

It runs in a browser tab. There is no VNC client to install, no SSH tunnel to hold open, and nothing to configure on your side.

Open It

Go to openclawlaunch.com/dashboard, find the instance, and click Desktop in the toolbar row beneath the main buttons — beside Files.

1. A new tab opens immediately showing “Starting Live Desktop”. It is a placeholder, not an error.
2. On a cold container the desktop takes roughly twenty to thirty seconds to install and start the first time. After that it is quick.
3. The tab then switches to the desktop itself, sized to your window. Resize the window and the remote screen resizes with it.

The button only appears while the instance is running, because the desktop is started inside a live container — there is nothing to attach to on a stopped or sleeping one. Start the instance first.

Desktop and Browser Are Two Different Screens

This trips people up, so it is worth stating plainly. Your instance has two screens, not one:

• The desktop screen, inside your agent’s own container. This is the terminal, the file manager and the agent’s GUI apps — the real machine.
• The browser screen, in a separate sandboxed container next to it. That is what Live Browser streams.

They are deliberately kept apart. A shared screen is not a video feed — any program on it can type into other windows on the same screen, read them, and take the clipboard. Since the browser is the part of the system most exposed to hostile web pages, letting it share a screen with your terminal would quietly undo the isolation the separate container exists to provide. Keeping two screens costs a little memory and buys a boundary that actually holds.

Practically, the desktop’s browser launcher brings that second screen in as a window, so you still get one place to look. Opening the desktop also wakes the browser side, so the launcher has something to show without you having to click Live Browser first.

What It Is Good For

• Seeing what the agent is doing. Watching a long task is far more informative than reading its summary afterwards.
• Fixing something by hand. Open the terminal, edit a file, rerun a command, and let the agent carry on.
• Anything that needs a GUI. Tools that assume a screen work here; on a headless container they simply do not run.
• Teaching. A recorded desktop session explains an agent workflow in a way a transcript never quite does.

Desktop, Live Browser, Terminal — Which One?

• Web task blocked on a login or captcha: Live Browser. It is the smallest tool for that job.
• Editing files or running commands and nothing more: the web terminal and file manager, or SSH access. Both are lighter than a streamed desktop.
• Wanting the whole machine — several windows, a GUI app, a terminal and the browser side by side: Desktop.

OpenClaw and Hermes

The button, the start sequence and the viewer are the same on both frameworks; the feature belongs to the hosted container, not to the agent runtime. What you find on the desktop differs only in the way the two frameworks lay out their own files — OpenClaw keeps its workspace and configuration under its own home directory, Hermes under its data volume. See the Hermes workspace and the OpenClaw architecture guide for what lives where.

Coding workspaces are the exception: they are not bot instances and do not get a desktop. Use their own terminal instead — see coding workspace hosting.

Self-Hosting the Same Thing

On your own box the ingredients are an X server, a VNC server bound to it, a websocket bridge, and noVNC served over TLS — plus a window manager and a couple of applications so the screen is not empty. Start them inside the agent’s own container if you want the desktop to be the agent’s real machine; start them in a sidecar if what you actually want is a browser screen.

The part that deserves care is access. A VNC endpoint on a public address is a remote session for anyone who finds it, so put an authenticating proxy in front of the websocket and mint short-lived, single-use tokens rather than leaving a password on the port. On managed hosting that layer is what the Desktop button is quietly using.

Troubleshooting

• No Desktop button. The instance is not running, or it is a coding workspace rather than a bot. Start it, or use the workspace terminal.
• The tab is blocked. Some browsers suppress the new tab if the click was not registered as a direct gesture. Allow pop-ups for openclawlaunch.com and click again.
• Stuck on “Starting Live Desktop”. First start on a cold container is slow. If it has not resolved after a minute, close the tab and click Desktop again — a new session is minted each time.
• Desktop opens but the browser window is empty. The browser side was still waking. Give it a moment, or open Live Browser from the dashboard once and retry the launcher.
• It disconnects when you leave it. Sessions are short-lived by design. Reopen from the dashboard; nothing on the machine is lost.

Try It

Deploy an instance from the homepage, wait for it to reach running, and click Desktop. Ask the bot to create a file in its workspace while the desktop is open, and watch it appear in the file manager.

Related: Live Browser, web terminal and file manager, SSH access, Hermes hosting.