agent-workspace-linux

A Rust MCP server that gives an agent its own hidden Linux desktop: an Xvfb display with an Openbox window manager, its own clipboard, and a Chrome instance the workspace owns. The agent launches apps, types, clicks, takes screenshots and drives the browser there, and the person's real mouse, keyboard, focus and logged-in Chrome stay out of it. A small GPUI viewer window shows the hidden screen and lets a human pause it, set it read-only, or stop it. Published by agent-sh, the same org as agentsys; the LICENSE reads © avi-fenesh.

Repo facts (GitHub API, read 2026-09-23): MIT, Rust, 111★, created 2026-05-23, last push 2026-09-20, latest release v0.3.3 (2026-09-19), releases roughly every two to four weeks since v0.2.1 in July. Prebuilt x86_64 and aarch64 binaries with .sha256 sidecars; an npm wrapper downloads them and checks the hash. Linux and X11 only; the README calls it pre-1.0 and says tool schemas can change.

What it is for

The README frames it by what it is not: agents that "use a computer" usually take over your screen. Its sibling in the same org, computer-use-linux (600★, AT-SPI / GNOME Shell / Wayland portals / ydotool), does exactly that on purpose. This one is the inverse. The stated uses are QA of a GUI app or a website without hijacking the live desktop, browser automation in a throwaway profile, and a desktop for a headless or long-running agent that nobody is watching.

Who owns the boundary

The README spends its longest table on one question, who sets the limits, and answers it in four layers:

Scenario	Boundary owner	Enforced by
Default, no `--permissions`	the agent host (Claude Code, Codex …)	nothing in the MCP; it defers to the host's approval flow
`--permissions file.json` or `AGENT_WORKSPACE_PERMISSIONS`	the developer who launched it	network mode, mounts and an app allowlist, checked at the MCP front-end and again at the daemon's IPC socket
Viewer pause / read-only	the human watching	a convenience, "not the security boundary"; mutating IPC fails closed if the control state can't be read
Workspace vs. host	the runtime	input, screenshots, clipboard and browser target the hidden display only

The ceiling can't be widened at runtime, only by restarting the server with a new file. Checking it twice matters because apps launched inside the workspace, and any other process running as the same user, can talk to the daemon directly. docs/permission-model.md says the ceiling is implemented and covered by tests, and that the human-approval side (a richer flow in "Codex for Linux") is still being built. Creating a workspace needs an explicit --ack-hidden-workspace flag, so it is never silent; after that one acknowledgement, the design wants workspace-local actions to run without "a second generic permission prompt storm".

Isolation of mounts and network uses bubblewrap when it is installed. When it isn't, the README says, the policies are "declared but not enforced", and doctor reports which. The control socket is a same-uid Unix socket (mode 0600) with no cross-user protection by design; SECURITY.md recommends a dedicated user on shared machines.

Browser control without the host's Chrome

Browser tools talk to a workspace-owned Chrome over a loopback DevTools port, never to the person's own browser. That makes it one concrete answer to the executor question claude-browser-use leaves open: Anthropic's toolset sends requests, and the developer has to supply the browser. The README also documents one Chrome detail: DevTools binds to an ephemeral port, and Chrome rejects WebSocket upgrades whose Origin isn't allow-listed including the port, so no fixed --remote-allow-origins value works. Its fix is to omit the Origin header rather than pass *, which would switch off that CSRF protection.

A helper script copies a real Chrome profile (after the human approves the directory) into a disposable one, to test logged-in Slack or GitHub sessions inside the workspace.

Progressive tool loading

The server exposes about 86 tools. To keep them out of the context window it ships an agent skill whose short description is the only thing loaded up front; the skill routes by phase (orient → start → observe → act → stop) and pulls tool schemas on demand. The installer puts it in ~/.codex/skills/ by default and takes --skills-dir ~/.claude/skills for Claude users. The same move agentic-awesome-skills makes with a catalog, applied here to one large MCP.

What the source does not show

No measurement of any kind. No task success rate, no latency, no comparison with driving the real desktop. Tier T1 covers the design as stated by its maintainers; how well it works is unknown here.
The security policy lags the releases. SECURITY.md lists only 0.1.x as supported, and says only that line gets fixes, while the current release is v0.3.3.
The README carries an ad for the author's own company. A banner promotes "tiyuvta inference" for running agents 24/7; avi-fenesh's own site lists the author as founder of tiyuvta. The README doesn't say so.
"Codex for Linux" and its "Agent Workspaces" page are referenced as the main integration target. The source doesn't explain what that product is, and nothing in this corpus pages it.

agent-sh · agentsys · claude-browser-use · agent-scope-isolation · model-context-protocol · agent-skills · agent-guardrails · agent-permission-model