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 repository description calls it "Go Native cross-platform RPA, GUI automation, Auto test and Computer use". 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_mac.go, robotgo_win.go, robotgo_android.go, robotgo_purego.go and libei.go, plus directories named darwin/, libei/, mouse/, key/, clipboard/, cv/ and event/. On Linux with X11, the README requires GCC, libc headers and X11/XTest headers at build time and an X server with XTEST and DISPLAY set at runtime, plus additional packages for the clipboard, bitmap and the event hook.

The Wayland backend is different in kind. The README's backend table lists a Wayland package selected with the wayland build tag, which builds with CGO_ENABLED=0 and needs a wlroots compositor, and a libei package that uses the RemoteDesktop portal on GNOME and KDE.

Installing RobotGo and moving the mouse from Go

The README lists Go 1.26+ and one backend as requirements: either the default Cgo backend (CGO_ENABLED=1, a C compiler and the platform libraries) or a tested pure-Go backend. 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 notes that the Bitmap package needs libpng headers (libpng++-dev on Ubuntu) and that it ships libpng for MinGW-w64 only. 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's default backend is Cgo (CGO_ENABLED=1), and the README also documents tested pure-Go backends that build with CGO_ENABLED=0 selected by a build tag. 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. With a pure-Go backend the C toolchain is not needed, but Bitmap and GoHook are separate Cgo packages that keep their C requirements.

The second boundary is the display. Automation that moves a mouse and captures a screen needs a session to talk to. The README's table says the Wayland backend needs a wlroots compositor and the libei backend uses the RemoteDesktop portal on GNOME and KDE.

The third boundary is stability. The most recent release is v1.3.7, published on 2026-10-22, following v1.3.6 on 2026-10-16 and v1.3.5 on 2026-10-07. 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.

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 a 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-10-27. Recent releases are v1.3.5 on 2026-10-07, v1.3.6 on 2026-10-16 and v1.3.7 on 2026-10-22, so the project is being worked on. The README's own pointer to a deprecated API docs page suggests documentation is trailing the code.

The go.mod file requires Go 1.26.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 licence terms of gosseract and the OCR engine it uses are not covered here.

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, or for GNOME or KDE Wayland input through the wlroots path. Before committing, verify that your target compositor is a wlroots compositor or that the RemoteDesktop portal is available.

Frequently asked questions

Official sources

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