Hermes Desktop on Linux with Bubblewrap
Keep the official interface in its own window without giving the app your home, X11 or session services.
Rota Nacional · Published · Reviewed
Isolate the interface process too
Building an app does not make its dependencies trusted. The Electron interface has its own processes and can start other programs. Isolating only the agent terminal leaves this part outside the boundary.
Bubblewrap creates the restricted environment. Its arguments define what the app can see. In this installation, Hermes Desktop light was built in Docker. The package ran in Bubblewrap and connected to the agent in another container.
Mount a minimal file system
- Start with --unshare-all --die-with-parent --new-session --cap-drop ALL --clearenv. First check that Linux permits the required user namespaces.
- Mount /usr and the app package read only. Create private /proc and /dev mounts. Use size limits for the /tmp and shared memory tmpfs mounts.
- Mount an empty dedicated directory as HOME. Set HOME, XDG_CONFIG_HOME, XDG_CACHE_HOME and XDG_DATA_HOME to internal paths. Do not mount the real personal home.
- Provide only the private agent socket and that session's token. Do not provide Docker, SSH, GPG or D-Bus sockets.
Provide a window without sharing X11
In an X11 session, sharing /tmp/.X11-unix and the user's authorization weakens the boundary. The app can then contact the display server used by other windows. In the validated setup, a trusted Weston created an outer window. Only that compositor's Wayland socket entered Bubblewrap.
Weston used the x11 backend, the pixman renderer and kiosk-shell.so. Electron used --ozone-platform=wayland --disable-gpu --disable-audio-output. The app received no DISPLAY, XAUTHORITY, GPU devices or audio access. The external launcher kept the access needed by the compositor.
The launcher associated the outer window with a dedicated desktop entry. On X11, WM_CLASS and StartupWMClass let the desktop identify the app in the dock. That visual identity grants no host access.
Separate the agent channel from the computer network
With --unshare-all, the interface's localhost belongs to the isolated environment. An internal relay connected 127.0.0.1:9119 to the private agent Unix socket. HERMES_DESKTOP_REMOTE_URL pointed to that internal address.
The token used Hermes' own session contract. A configuration request without a token was refused. The same request with the token succeeded. No agent port needed to be open on the host. The launcher renewed the token and stopped the processes when the window closed.
Check the version you will use
The local check on 4 November 2026 used client and agent 0.22.6. All 14 interface checks and seven agent checks passed. Startup, navigation and settings were inspected. The check did not include a model response because no key was registered.
Microphone, screen capture, notifications and file integration were reduced. Do not restore a feature by sharing the whole session. Assess a specific permission and repeat the check. Bubblewrap still shares the kernel. It does not replace a virtual machine.
Frequently asked questions
Is the Electron sandbox enough?
The internal sandbox protects parts of Electron. The external profile also limits the main process and programs it starts. Check both in the selected version.
Must I replace my X11 session with Wayland?
The validated setup kept the X11 session. Weston ran as a nested compositor and gave the app a separate Wayland socket.
Keep reading
How to limit an AI agent with Docker
Separate agent files, limit resources and close the network. See the profile used for Hermes and the role of Rota Nacional.
Build agents without exposing the desktop to dependencies
Pin the source, inspect the package graph and build without a network in Docker. Isolation remains necessary after the app is built.
Connect an agent to RN through a restricted network
Use a fixed destination channel, a dedicated key and the correct API contract. Understand access control and the privacy barrier.