RobotGo: Golang Desktop Automation for Mouse, Keyboard, and Screen

What RobotGo Automates and Who Uses It

RobotGo provides Go programs with control over the desktop: moving the mouse, clicking, typing text, capturing screenshots, reading window titles and positions, and listening for global input events. The README describes its scope as "Golang Desktop Automation, auto test and AI Computer Use" and lists the controllable surfaces as "mouse, keyboard, read the screen, process, Window Handle, image and bitmap and global event listener".

The primary users are developers writing GUI test automation in Go, building robotic process automation pipelines that interact with desktop applications, or implementing computer-use agents that need to observe and control a graphical interface programmatically. The Apache-2.0 license and Go module structure make it straightforward to embed in both open-source and commercial tools.

Platform Coverage and Build Prerequisites

RobotGo supports Mac, Windows, and Linux on both arm64 and x86-amd64, as stated in the README. The standard build uses cgo to bind against native system libraries, which means each platform has prerequisites beyond a Go installation.

On macOS, the build requires Xcode Command Line Tools and the accessibility and screen recording permissions granted in System Settings:

xcode-select --install

MacOS also requires granting privacy permissions under System Settings > Privacy & Security > Accessibility and Screen & System Audio Recording.

On Windows, a GCC toolchain is required. The README recommends llvm-mingw, installable through winget:

winget install MartinStorsjo.LLVM-MinGW.UCRT

On Linux, the Ubuntu dependency set covers the X11 development headers, clipboard tools, and the GoHook event library:

sudo apt install gcc libc6-dev
sudo apt install libx11-dev xorg-dev libxtst-dev
sudo apt install xsel xclip
sudo apt install libpng++-dev
sudo apt install xcb libxcb-xkb-dev x11-xkb-utils libx11-xcb-dev libxkbcommon-x11-dev libxkbcommon-dev

Fedora uses equivalent dnf packages for X11, clipboard, bitmap, and hook dependencies.

Installing RobotGo in a Go Module Project

With Go module support (Go 1.11 and later), RobotGo is imported directly:

import "github.com/go-vgo/robotgo"

For projects not yet using Go modules, the README gives the direct get command:

go get github.com/go-vgo/robotgo

To update to the latest version:

go get -u github.com/go-vgo/robotgo

The README notes a known C file compilation cache problem with go1.10.x (golang issue 24355) and a `go mod vendor` problem (golang issue 26366). Current Go versions should not encounter these, but they are documented as known historical issues.

After importing, the examples/ directory contains runnable programs demonstrating mouse, keyboard, screen, and window control. The examples/README.md describes each subdirectory.

Cgo-Free Backends for Portability and Cross-Compilation

RobotGo ships experimental pure-Go backends for every supported platform. These backends expose the same API as the cgo build, so existing code requires no changes, only a build tag switch. They cross-compile with `CGO_ENABLED=0`, which means no GCC, MinGW, Xcode, or X11 headers are needed.

The available backends and their build tags are:

| Backend | Build tag | |---|---| | Windows (Cgo-free) | win | | macOS (Quartz via purego) | mac | | X11 (pure-Go X protocol) | x11 | | Wayland (wlroots) | wayland | | libei (GNOME/KDE portal) | libei |

The Wayland backend requires a wlroots-based compositor. The README explicitly lists compositors that support the needed protocols (Sway, Hyprland, Wayfire) and states that GNOME and KDE do not support these protocols natively. The libei backend fills that gap for GNOME and KDE by going through the xdg-desktop-portal RemoteDesktop interface. However, the README notes that the libei backend handles mouse and keyboard only: screen capture and window management return ErrNotSupported.

These cgo-free paths are described as experimental. They should be validated against the specific platform and compositor version before use in production automation.

Where RobotGo Falls Short

The accessibility permission requirement on macOS is a meaningful operational hurdle. Any machine running RobotGo-based automation must have the binary explicitly listed under Accessibility in System Settings. This approval cannot be scripted silently on recent macOS versions, which makes unattended deployment on macOS more involved than on Linux or Windows.

The libei backend for GNOME and KDE is limited to input injection only. Screen capture and window management are not supported through that backend. A Go program that needs to automate GUI workflows on a GNOME Wayland desktop (observing screen state and injecting input in response) cannot do both through a single cgo-free backend.

RobotGo does not provide image recognition or OCR for identifying UI elements by their visual appearance. The bitmap functions cover pixel comparison and screenshot capture, but identifying a button by what it looks like (matching a template image) requires additional tooling. The go.mod shows an OCR dependency (github.com/otiai10/gosseract/v2) in the project, but the core README does not document an integrated image recognition workflow.

The v2.0.0 release is in beta (v2.0.0-beta4 as of September 21, 2026). Code targeting v2 APIs should be treated as targeting an unstable interface until the stable release is out.

PyAutoGUI as the Comparison Point and License Terms

PyAutoGUI is the most direct alternative for desktop automation if the Go constraint is relaxed. Both libraries control mouse, keyboard, and screen on multiple platforms. PyAutoGUI is Python-based, uses similar cross-platform abstractions, and includes screenshot comparison and image recognition through Pillow and OpenCV integrations. The fundamental difference is language: RobotGo targets Go programs and compiles to a binary, while PyAutoGUI scripts run in a Python interpreter. For teams already in Go and wanting automation in the same language, RobotGo avoids a Python subprocess. For teams without a Go build pipeline, PyAutoGUI is the lower-friction starting point.

RobotGo is licensed under Apache-2.0. Apache-2.0 permits use, modification, and distribution in commercial products and requires preserving copyright notices and the license text. It also includes a patent grant clause that is absent from MIT, which is relevant for organizations with specific patent licensing requirements.

The most recent stable release is v1.1.0, published on September 22, 2026. The last push to the repository was on September 22, 2026.

Editorial conclusion

RobotGo is a practical choice for Go developers writing desktop automation scripts, GUI tests, or RPA workflows on Mac, Windows, or Linux. The cgo dependency on the standard build means the platform prerequisites (GCC, X11 headers on Linux, Xcode CLI tools on macOS, MinGW on Windows) must be satisfied before the first build. Evaluate the cgo-free experimental backends if cross-compilation or a simpler build pipeline matters. For Wayland users on GNOME or KDE, test the libei backend against your specific portal version before committing to RobotGo for a production workflow.

Frequently asked questions

Official sources

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