{
  "markdown": "# Deskwright\n\n[![CI](https://github.com/tristanmuzzu/deskwright/actions/workflows/ci.yml/badge.svg)](https://github.com/tristanmuzzu/deskwright/actions/workflows/ci.yml)\n[![PyPI](https://img.shields.io/pypi/v/deskwright.svg)](https://pypi.org/project/deskwright/)\n[![License](https://img.shields.io/badge/license-Apache--2.0-blue.svg)](LICENSE)\n[![GNOME Shell](https://img.shields.io/badge/GNOME%20Shell-48--50-4a86cf)](#requirements)\n[![Wayland](https://img.shields.io/badge/Wayland-native-blue)](#how-it-actually-works)\n\n**Computer use for AI agents on GNOME Wayland.**\n\nLet your coding agent use your Linux desktop. Or give it one of its own, so it\nstops stealing your mouse.\n\n[Install](#install) &nbsp;•&nbsp;\n[What it can do](#what-it-can-do) &nbsp;•&nbsp;\n[A desktop of its own](#a-second-desktop-it-uses-while-you-work) &nbsp;•&nbsp;\n[When something's off](#when-somethings-off) &nbsp;•&nbsp;\n[Security](SECURITY.md)\n\n<!-- demo.gif goes here: split screen, you typing on the left, the agent\n     driving apps on a virtual monitor on the right, uninterrupted. -->\n\nClaude Code can edit your files and run your commands. It can't open GIMP,\nclick a button in a settings dialog, or read what a native app is showing you.\nOn macOS and Windows it can, through computer use. On Linux that's still on\nAnthropic's list.\n\nThis fills the gap on GNOME. It's an MCP server plus a small shell extension,\nand it hands an agent the actual desktop: launching apps, reading widgets,\nclicking, typing, dragging, window management, OCR and screen recording. Any\nMCP client can drive it. Claude Code, Codex, Cursor, your own script.\n\nThe part people tend to like most: `DESKWRIGHT_SESSION=headless` runs all of\nit on a virtual monitor that isn't on any of your screens. Your agent gets a real GNOME\ndesktop to work on, and it never takes your focus.\n\n## Why this exists\n\nWayland deliberately stops an application from seeing or touching any other\nwindow. That's a good rule, and it's why `xdotool`, `wmctrl` and `grim` either\ndo nothing on GNOME or fail in ways that look like your own mistake. Every\nLinux computer-use project I found either shipped a Docker container running\nX11, or quietly assumed X11 and broke.\n\nSo I went looking for what GNOME actually permits, and it turns out to be quite\na lot, just not where anyone looks. Mutter answers D-Bus. AT-SPI, the\naccessibility layer built for screen readers, exposes every real widget in\nevery running app with its name, its role and the action it performs. And a\nshell extension runs inside gnome-shell itself, where the rest lives.\n\nThat middle one matters more than it sounds. Pressing a widget's own\naccessibility action isn't a nicer way to click. It's a different thing: it\ncan't miss, it survives the window moving, and it needs no pointer at all. An\nagent working this way stops guessing at coordinates, and stops taking a\nscreenshot after every action to find out what happened.\n\n## Install\n\nYou need GNOME Shell on Wayland. Check with `echo $XDG_CURRENT_DESKTOP\n$XDG_SESSION_TYPE`, which should mention GNOME and wayland.\n\n### The lazy way: hand it to your agent\n\nOpen Claude Code, or Codex, or whatever you use, and say:\n\n> Set up https://github.com/tristanmuzzu/deskwright on this machine,\n> follow the AGENTS.md.\n\n[`AGENTS.md`](AGENTS.md) is a runbook written for agents. Every command, how to\ncheck each one worked, the right package names for Debian, Fedora and Arch, and\nthe handful of things that go wrong with their fixes. Your agent will ask you\nfor a sudo password once and tell you to log out once. That's your whole\ninvolvement.\n\n### By hand: two commands and a logout\n\n```bash\npipx install --system-site-packages deskwright\ndeskwright-setup\n```\n\n`deskwright-setup` narrates every step. It turns on the accessibility flag, installs\nthe bundled shell extension, and tells you about any missing system package\nwith the right install line for your distro, so you're never guessing at\npackage names. It never runs sudo itself.\n\n**Then log out and log back in.** Once. There's no way around this one: on\nWayland, gnome-shell only picks up an extension at session start.\n\nLast step, point your client at it:\n\n```bash\nclaude mcp add deskwright --scope user -- deskwright\n```\n\nThat's it. Ask your agent to open an app and it will.\n\n<details>\n<summary><b>Why <code>--system-site-packages</code>, and what breaks without it</b></summary>\n\nPyGObject publishes no wheels to PyPI. It's a distro package everywhere\n(`python3-gi`, `python3-gobject`, `python-gobject`), so an isolated venv can't\nimport it. Leave the flag off and you get a server that starts cleanly and then\ndies on the first click with `input_backend_failed`.\n\n`uvx` has no equivalent flag, which is the only reason this says pipx. If you'd\nrather skip pipx, a plain `python3 -m venv --system-site-packages` followed by\n`pip install deskwright` works identically.\n</details>\n\n<details>\n<summary><b>As a Claude Code plugin instead</b></summary>\n\nThe repo is also a plugin marketplace. It registers the server plus a skill\nthat teaches an agent which tool to reach for first.\n\n```bash\nclaude plugin marketplace add tristanmuzzu/deskwright\nclaude plugin install deskwright@deskwright\n```\n\nThe plugin runs the server from its own checkout, so there's no pip install.\nYou still need the system packages and the extension, so run the setup out of\nthe checkout Claude Code cloned for you, once:\n\n```bash\n~/.claude/plugins/marketplaces/deskwright/bin/deskwright-setup\n```\n\nThen log out and back in, same as above.\n</details>\n\n<details>\n<summary><b>From a clone, if you want to hack on it</b></summary>\n\n```bash\ngit clone https://github.com/tristanmuzzu/deskwright\ncd deskwright\nbin/deskwright-setup\n./mcp_server.py --self-test\n```\n\n`./mcp_server.py` is the same entry point as the `deskwright`\ncommand, by the path older registrations already point at.\n[`CONTRIBUTING.md`](CONTRIBUTING.md) has the layout and which test suites need\na real session.\n</details>\n\n## Check it works\n\n```bash\nDESKWRIGHT_SESSION=headless deskwright --self-test\n```\n\nYou want `18/18 passed`. It runs on a virtual monitor rather than your screen,\nso it's safe to run while you're working. The first run takes about 20 seconds\nbecause it has to start a second gnome-shell.\n\nDrop `DESKWRIGHT_SESSION=headless` and it tests your real desktop instead. Do that one\nwhile you're looking at the screen: the self-test injects real input, because\nit's checking the guards that refuse dangerous key combinations.\n\nWhen something's wrong, ask your agent to call `desktop_health`. It answers in\none line whether this desktop is usable, then says which mechanisms work right\nnow and what each of them will actually do.\n\n## What it can do\n\n33 tools, roughly 11k tokens of schema in a session. That's the honest price,\nand it's why each one returns enough that you don't need a second call to work\nout what happened. The order below is the order an agent should reach for them.\nAccessibility tree first, pixels last.\n\n| Tool | What it's for |\n|---|---|\n| `ui_apps`, `ui_tree`, `ui_find` | Find things. `ui_find` searches 30 levels deep by default, because GTK4 nests far deeper than you'd expect. |\n| `ui_press` | **The good one.** Invokes the widget's own action, so it can't miss. Wants `expect_name` or `expect_role`, which is the identity check, not ceremony. |\n| `ui_set_text` | **The good one for typing.** Writes straight into the widget with no focus and no keyboard, then reads it back to prove the write landed. |\n| `ui_read_text` | Read a widget's contents. This is how you verify something worked. |\n| `launch_app` | Start an app by desktop id and wait for its window, inside one call. |\n| `screen_map` | Where everything is, in pixels: windows top of stack first, plus every pressable widget of the focused app with the point to click it at. Each carries a `ref: N` you pass straight to `ui_press` or `pointer_click`. No coordinates to copy, identity re-checked on use. |\n| `pointer_click`, `pointer_move`, `pointer_drag`, `pointer_scroll` | Real pointer input in absolute screen coordinates. Pass `expect_window` and a click that would land somewhere else is refused, with the blocker named so you can redirect in the same call. |\n| `window_at`, `pointer_position` | What a click at a point would hit, before you click it. And where the pointer is now, or an honest note that only the last position it set is known. |\n| `find_text` | Where a visible string is, in screen coordinates. OCR, about 0.3s for a window, and no image in your transcript. This is the answer for Chrome, Electron and Qt, which expose almost nothing to `ui_find`. |\n| `wait_for` | Wait for a window, a widget, some text, a focus change or the clipboard, instead of sleeping a guessed number of seconds. |\n| `region_changed` | Wait for pixels to change. For what `wait_for` can't express, like a reply arriving or a spinner stopping. |\n| `assert_state` | Pass or fail with evidence, so a long run can decide for itself that it's finished. |\n| `do_steps` | A known sequence in one call, validated before anything runs, with per-step retry and one picture at the end, or at the step that broke. |\n| `list_windows`, `activate_window`, `window_manage` | Window list, focus, and move, resize, close, minimize, maximize, workspace. |\n| `screenshot`, `zoom` | A picture, or a full-resolution crop of one window, region or widget. `zoom` never scales, so small text stays readable. |\n| `screencast`, `frames` | For anything that moves, because a still can't show motion. `frames` also reports a per-frame delta series, which is how you tell a smooth scroll from a juddering one. |\n| `type_text`, `press_keys`, `hold_key` | Keyboard input through compositor keysyms, with focus proven before anything gets typed. |\n| `clipboard_read`, `clipboard_write` | Pasting beats two thousand keystrokes, and reading back is how you check it arrived. |\n| `journal` | The trail of everything the agent did: arguments, outcome, whether it landed, screenshot hashes. For reviewing an unattended run, or working out where you are after a context reset. |\n| `desktop_health` | One line on whether this desktop is usable, then the detail. |\n\n## A second desktop it uses while you work\n\nAn agent that needs your screen is only half useful. `deskwright-headless` starts a\nseparate GNOME session on a virtual monitor, with its own session bus, its own\n`gnome-shell --headless` and its own runtime directory. A server pinned to it\ndrives that desktop with the same 33 tools while you keep the physical one.\n\n```bash\ndeskwright-headless start                    # about 200 MB of gnome-shell, idempotent\ndeskwright-headless status                   # liveness, memory, bus address\ndeskwright-headless stop                     # don't leave it idling on an 8 GB machine\n```\n\nRegister it as a second MCP server and you can hand it long jobs:\n\n```bash\nclaude mcp add deskwright-headless --scope user --env DESKWRIGHT_SESSION=headless -- deskwright\n```\n\nSessions are named, so two agents can each have a desktop of their own and\nnever watch each other's windows move:\n\n```bash\ndeskwright-headless start --name work\ndeskwright-headless list                     # every session, memory used, memory free\nDESKWRIGHT_SESSION=headless:work deskwright\n```\n\nGive a session its own home and it boots a GNOME that has never been used: no\ndesktop icons, no session restore, no recent files. That is what you want for\na recorded demo or a clean-room test, where the default behaviour of sharing\nyour home means an editor opens your last document.\n\n```bash\ndeskwright-headless start --name demo --home /tmp/demo-home\n```\n\nThere are guards on this, because each session is a real compositor at around\n205 MB: a per-name start lock so two agents can't both spawn one, a session cap\n(`DESKWRIGHT_HEADLESS_MAX`, default 4), and a free-memory floor that refuses a start\nwhich would push the machine into swap. The agent that would cause that can't\nsee it coming, so the server does.\n\n## When something's off\n\n**The extension says INACTIVE, or window tools don't work.** You haven't logged\nout yet. gnome-shell can't load an extension without a session restart and\nthere's no workaround. Until then you still get AT-SPI, pointer, keyboard and\nclipboard. You don't get window management, extension screenshots, pointer\nposition or the halt switch.\n\n**An app shows no widgets in `ui_tree`.** It was already running when\n`toolkit-accessibility` got turned on. Apps read that setting at startup, so\nrestart the app.\n\n**Chrome, Electron or Qt apps look empty.** As far as AT-SPI is concerned, they\nare. Use `find_text` instead, which OCRs the screen and hands back coordinates.\nFor Chrome specifically, launching it with `--force-renderer-accessibility`\ngets you a real tree at a small performance cost.\n\n**Everything fails with `input_backend_failed`.** pipx without\n`--system-site-packages`. Reinstall with the flag:\n\n```bash\npipx install --force --system-site-packages deskwright\n```\n\n**Every `ui_*` call says \"Namespace Atspi not available\".** You have\n`python3-gi` but not the AT-SPI typelib, which is a separate package:\n`gir1.2-atspi-2.0` on Debian and Ubuntu, `at-spi2-core` on Fedora and Arch.\n`deskwright-setup --check` catches this and names it.\n\n**A tool returns `halted`.** Somebody pressed `Super+Ctrl+Escape`, which is the\nhalt switch. Press it again to clear it.\n\n**Your screen locked and half the tools stopped.** Expected. GNOME unloads\nextensions that don't declare `unlock-dialog`, so screenshots and window\ngeometry go away until you unlock. AT-SPI keeps working, so `ui_find`,\n`ui_press` and `ui_read_text` all still do.\n\n## What it won't do\n\nDeliberately out of scope as a project, not just off by default:\n\n- **No CAPTCHA solving.** CAPTCHAs exist to tell humans from software. This is\n  software.\n- **No credential typing features.** Nothing here is built to harvest, store or\n  autofill secrets. The journal doesn't record what gets typed, only how much.\n- **No detection evasion.** No timing jitter to look human, no fingerprint\n  spoofing, no anti-anti-bot work.\n- **No cloud, no telemetry, no account.** It's a local process on your session\n  bus, and nothing leaves the machine.\n\nOn the other side of that line the design is deliberately permissive. The agent\nis trusted, and the tooling's job is to make it capable rather than to fence it\nin. The whole safety budget goes to three things: a halt switch a human can\nalways reach, guards against actions that can't be undone, and an honest record\nof what happened. [SECURITY.md](SECURITY.md) is blunt about what enabling this\nactually switches on, and it's worth reading before you point it at your real\nscreen.\n\n## How it actually works\n\nWayland denies all of this to Wayland clients. It says nothing about D-Bus, and\nthat's where the doors are. Four mechanisms, roughly in order of how much work\nthey carry:\n\n1. **AT-SPI** for anything semantic. Real widgets, real actions, no pointer.\n2. **A gnome-shell extension** over D-Bus for what gnome-shell keeps to itself:\n   window enumeration and control, screenshots, pointer position, and a\n   keybinding grab for the halt switch.\n3. **`org.gnome.Mutter.RemoteDesktop`** for pointer and keyboard. Absolute\n   coordinates, and keysyms rather than key positions, so your keyboard layout\n   can't transpose what gets typed.\n4. **`xdg-desktop-portal`** for the same thing, standardised. This is the route\n   to compositors that aren't GNOME.\n\nWorth knowing: number 2 is the only one of those that isn't already open.\nMutter's ScreenCast and RemoteDesktop interfaces answer any client on your\nsession bus with no consent dialog, which is why recording here needs no\npermission popup, and why the portal is a caller of them rather than a gate in\nfront of them. [SECURITY.md](SECURITY.md) has the exact commands if you'd\nrather check that yourself than take my word for it.\n\n[`docs/field-notes.md`](docs/field-notes.md) is the long version: every wall\nhit on the way here, what the compositor refused, and the measurements that\nshaped the tool surface. It's the file to read when something behaves oddly, or\nbefore you change the code.\n\n## Requirements\n\n`deskwright-setup --check` is the real answer. It detects everything, names the\npackage for your distro and exits nonzero if a hard requirement is missing.\nThe short version:\n\n| Platform | Status |\n|---|---|\n| GNOME Shell 50 on Wayland | **Verified.** Developed on 50.1 (Ubuntu 26.04), live suites run against it on every change. |\n| GNOME Shell 48 to 49 | **Should work.** Same D-Bus and AT-SPI surfaces, not tested. Reports welcome, attach `desktop_health` output. |\n| KDE Plasma, Sway, Hyprland | **Input only.** The portal backend drives pointer and keyboard, but window management and screenshots need per-compositor work that isn't done. `desktop_health` will say it's not usable, and it means it. |\n| X11 | Not a target. `xdotool` already does this well there. |\n\n**Claude Code, not Cowork.** On Linux the desktop app runs Cowork tasks inside a\nQEMU/KVM virtual machine, so an MCP server it starts lives in that VM and cannot\nsee your session bus, your gnome-shell or your screen. Everything here would fail\nthere. Use it from the Claude Code CLI, the Code tab, or any other MCP client\nrunning on the host itself.\n\n**Claude Code, not Cowork.** On Linux the desktop app runs Cowork tasks inside\na QEMU/KVM virtual machine, so an MCP server it starts lives in that VM and\ncannot see your session bus, your gnome-shell or your screen. Everything here\nwould fail there. Use it from the Claude Code CLI, the Code tab, or any other\nMCP client running on the host itself.\n\nPackages, using Debian names (`deskwright-setup` prints yours): `python3-gi`,\n`gir1.2-atspi-2.0`, `python3-pil`, `libglib2.0-bin`, `wl-clipboard`,\n`tesseract-ocr`. `ydotool` is optional and only used as an input fallback. The\nheadless session additionally wants `gnome-shell` and `dbus-daemon` as\nbinaries, which any normal desktop already has.\n\n## Contributing, security, license\n\n[`CONTRIBUTING.md`](CONTRIBUTING.md) has the layout, the test suites and what\neach one needs. [`SECURITY.md`](SECURITY.md) is the threat model, stated\nplainly. [`ROADMAP.md`](ROADMAP.md) is what's next and why, in order.\n\nApache-2.0. If you get it running on a compositor that isn't GNOME, or on a\nGNOME older than 50, please open an issue and say so. That's the most useful\nthing anyone can send.\n\n<sub>`mcp-name: io.github.tristanmuzzu/deskwright`</sub>\n<!-- The line above is how registry.modelcontextprotocol.io proves the PyPI\n     package and the registry entry have the same owner. It reads the README\n     that ships with the package and looks for exactly that string. -->\n",
  "bytes": 18708,
  "sha": "cf9b8f2359cbbfb00cc51f2aec9adcda6d274148839644c3e8ac266651249a02",
  "repo_slug": "tristanmuzzu/deskwright",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_tristanmuzzu_deskwright_491bf419/readme"
}