RobotGo: cross-platform desktop automation in Go

What RobotGo solves, and who ends up using it

RobotGo is a Go library for driving a desktop the way a person does: moving the mouse, typing keys, capturing the screen, reading window handles, and listening for global input events. The README describes it as "Golang Desktop Automation, auto test and AI Computer Use," and the topic list on the repository names rpa, auto-test, computer-use, mouse, window and opencv. That combination points at a specific audience: Go developers who need to script a GUI that has no API, and test or agent authors who need to click and read pixels rather than call endpoints.

The alternative in pure Go is usually to shell out to platform tools or write per-OS syscall code yourself. RobotGo wraps those platform layers behind one import path, which is the real value. It is not a test framework and it does not give you assertions, retries or reporting. It gives you the primitives, and you build the harness around them.

How the backends are split across X11, Wayland, libei and the OS APIs

The repository layout shows the split clearly. There are top-level files such as robotgo_x11.go, robotgo_mac.go, robotgo_win.go and robotgo_android.go, plus directories named x11/, wayland/, libei/, win/, mouse/, key/, screen/, window/, clipboard/, cv/ and event/. On Linux with X11, the README requires "X11 with the XTest extension (the Xtst library)" and additional packages for clipboard, bitmap and the event hook.

The Wayland backend is different in kind. The README states it is "a pure-Go (Cgo-free) implementation, so no system C libraries are required," and that it needs a wlroots-based compositor supporting zwlr_virtual_pointer_v1, zwp_virtual_keyboard_v1, zwlr_screencopy_v1 and zwlr_foreign_toplevel_management_v1. It also states plainly that "GNOME and KDE do not support these protocols natively." The libei backend covers that gap by going through xdg-desktop-portal RemoteDesktop, but the README limits it: mouse and keyboard input only, while screen capture and window management report ErrNotSupported.

One detail in the libei section is worth reading twice. Because the portal never exposes the physical cursor, Location() returns the last position injected by robotgo, not movement made with the real mouse. If your automation reads the cursor to decide where to click next, that value will drift from reality as soon as a human touches the machine.

Installing RobotGo and moving the mouse from Go

The README says to make sure Golang and GCC are installed before installing RobotGo. With Go module support (Go 1.11+), the documented path is to import the package; otherwise the README gives go get. On Ubuntu the README lists the system packages, including libx11-dev, xorg-dev and libxtst-dev for X11, xsel and xclip for the clipboard, and the xcb and libxkbcommon packages for the event hook.

sudo apt install gcc libc6-dev
sudo apt install libx11-dev xorg-dev libxtst-dev
sudo apt install xsel xclip

On macOS the README points to xcode-select --install and to adding Screen Recording and Accessibility permissions under System Settings. On Windows it points to winget install MartinStorsjo.LLVM-MinGW.UCRT or a Mingw-w64 build, with the bin directory added to Path.

go get github.com/go-vgo/robotgo

The README also notes a common failure: "png.h: No such file or directory" links to issue 47, which is the libpng dependency used by the bitmap package. For updates, the README gives go get -u github.com/go-vgo/robotgo and warns about a Go 1.10.x C file compilation cache problem and a go mod vendor problem, both linked to upstream Go issues. The examples/ directory holds runnable programs for key, mouse, scale, screen and window, so the fastest first use is to read examples/main.go and the subdirectory that matches what you want to drive.

Where RobotGo is the wrong tool

The build requirements are the first boundary. RobotGo is a Cgo library on macOS, Windows and X11 Linux. That means a C toolchain in your build image, platform headers at compile time, and a binary that is tied to the platform you built it on. If your deployment target is a scratch container or a distroless image, you are shipping a compiled artifact with system library dependencies rather than a static Go binary.

The second boundary is the display. Automation that moves a mouse and captures a screen needs a session to talk to. The README's Wayland section requires a wlroots compositor with four specific protocols, and explicitly says GNOME and KDE do not support them natively. The libei path works on GNOME and KDE but, per the README, does not do screen capture or window management at all. So on a stock GNOME desktop, half of what RobotGo advertises is unavailable through the Wayland route.

The third boundary is stability. The most recent release is v2.0.0-beta3, published on 2026-09-09, following v2.0.0-beta2 and v2.0.0-beta1. These are beta releases. The README also marks the API Docs page as "Deprecated, no updated," which means the primary reference is GoDoc rather than a maintained prose document. If your project needs a frozen API and a support commitment, that combination is a reason to wait.

RobotGo compared with a browser-driven approach

The obvious alternative for user-interface automation is a browser driver such as Chrome DevTools Protocol tooling, or a page-level framework that drives a DOM. The difference is the layer it operates at. A browser driver talks to the browser's own automation protocol, so it can select an element by selector, wait for it to become visible, and read its text without touching pixels. RobotGo operates below that: it moves the physical pointer and reads the framebuffer.

That lower layer is exactly why RobotGo exists. It can drive a native desktop application, an installer, a legacy client or an embedded window that has no automation API, and it can do so across macOS, Windows and Linux from one Go codebase. The cost is precision and brittleness. A selector survives a window moving; a hardcoded coordinate does not. RobotGo gives you image and bitmap handling and OpenCV-related packages in the cv/ directory, which is the intended answer to that problem, but you are the one matching templates and deciding what counts as a hit.

There is also a commercial sibling. The README links to RobotGo-Pro for "the JavaScript, Python, Lua and others version, tech supports, new features and newest robotgo version ("no open-source version now")." That note says the newest version is not in the open-source repository, which is a fact worth knowing before you plan a long-lived integration on the community edition.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-09, the same day as the v2.0.0-beta3 release. Releases have been frequent across July, August and September 2026, so the project is being worked on. That is not the same as stable. Three beta releases in roughly two months means the v2 API is still moving, and the README's own pointer to a deprecated API docs page suggests documentation is trailing the code.

The go.mod file requires Go 1.25.0 and pulls in purego, godbus, xgb and xgbutil, gosseract for OCR, tailscale/win, vcaesar/go-wayland, gops, imgo, keycode, screenshot and tt. That is a wide dependency surface for a library that wraps operating system input. Each of those is a place where an upgrade can change behaviour, and the pure-Go Wayland and libei backends depend on protocol support in the compositor rather than on a version you control.

The licence is Apache-2.0, which is permissive and includes an explicit patent grant. That is a favourable position for commercial use compared with a copyleft licence. It says nothing about the RobotGo-Pro offering, which is a separate product with its own terms. Check the OCR dependency separately if you enable it: the README does not state which OCR engine gosseract binds to or what its licence obligations are, and that is a question for your own legal review rather than something this article can settle.

Editorial conclusion

Adopt RobotGo if you are writing Go and need real desktop input and screen capture on macOS, Windows or Linux, and you accept a Cgo build with GCC and platform libraries. Do not adopt it for headless CI without a display server, for GNOME or KDE Wayland input through the wlroots path, or if you need a stable non-beta release. Before committing, verify that your target compositor exposes the four wlroots protocols or that xdg-desktop-portal is running, and check whether the beta API surface matches the code you plan to ship.

Frequently asked questions

Official sources

1. go-vgo/robotgo on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases