Restart Browser Helper

Purpose

Restart the computer-use browser stack that Hermes uses for web automation, screenshots, and VNC/noVNC access.

Symptoms that match this runbook

• Browser screenshots are failing
• cua-driver MCP tools return errors
• VNC/noVNC is unreachable on 5901 / 6081

Prerequisites

• Display helper already running: Xvfb :99, x11vnc on 127.0.0.1:5901, noVNC at 127.0.0.1:6081
• cua-driver binary installed at /home/hermes/.cua-driver/packages/releases/0.9.0-x86_64-unknown-linux-gnu/cua-driver
• Browser VM/desktop helper is expected but not mandatory

Procedure

1. Inspect current browser helpers

ps aux | grep -E "cua-driver serve|x11vnc|fluxbox|vnc-watcher" | grep -v grep

2. Stop cua-driver only

pkill -f "cua-driver serve"

3. Start cua-driver

/home/hermes/.local/bin/cua-driver serve

Run in background or a tmux/screen session if needed.

4. Verify ports remain available

nc -z 127.0.0.1 5901 && echo "x11vnc ok" || echo "x11vnc missing"
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:6081/

5. Restart full browser VM stack only if step 4 fails

pkill -f "Xvfb :99"
pkill -f "x11vnc"
pkill -f "fluxbox"
/home/hermes/.local/bin/cua-driver serve

Verification

• cua-driver serve process is present in ps
• 5901 and 6081 are reachable
• No zombie accumulation in browser/desktop processes

Rollback

• If browser automation is not mission-critical, skip full VM restart and continue without it
• Do not stop gateway or dashboard unless necessary

Notes

• This runbook assumes the standalone desktop helper is running separately from Hermes core
• The browser backend path can work without browser automation; this stack is optional depending on task

Last tested

2026-07-22

Related

• browser-backend
• restart-hermes