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

> RobotGo is an Apache-licensed Go library for cross-platform desktop automation, covering mouse control, keyboard simulation, screen capture, window management, and global event hooks. It targets Go developers who need to automate GUI applications on Mac, Windows, or Linux without a heavyweight testing framework.

**go-vgo/robotgo** — RobotGo, Go Native cross-platform RPA, GUI automation, Auto test and Computer use  @vcaesar

- Repository: https://github.com/go-vgo/robotgo
- Website: https://atomai.cc
- Stars: 10,845 · Forks: 961
- Language: Go
- License: Apache-2.0
- Published: 2026-09-16 · Updated: 2026-09-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/go-vgo-robotgo

## 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:

```bash
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:

```bash
winget install MartinStorsjo.LLVM-MinGW.UCRT
```

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

```yml
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:

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

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

```bash
go get github.com/go-vgo/robotgo
```

To update to the latest version:

```bash
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.

## 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.

## FAQ

### Does RobotGo require GCC to build on Linux?

Yes, the standard cgo build on Linux requires GCC, X11 development headers, xsel or xclip for clipboard support, libpng for bitmap operations, and xcb/xkb libraries for the GoHook event listener. The README lists the exact apt packages for Ubuntu and dnf packages for Fedora. The experimental cgo-free X11 backend builds with CGO_ENABLED=0 and needs none of those system libraries.

### Does RobotGo work on Wayland desktops?

RobotGo includes a pure-Go Wayland backend for wlroots-based compositors such as Sway, Hyprland, and Wayfire. The README states that GNOME and KDE do not support the required wlroots protocols natively. A separate libei backend handles GNOME and KDE through the xdg-desktop-portal RemoteDesktop interface, but that backend supports mouse and keyboard input only, not screen capture or window management.

### What platforms and architectures does RobotGo support?

The README states RobotGo supports Mac, Windows, and Linux. It supports both arm64 and x86-amd64 architectures on all three platforms.

## Sources

- [go-vgo/robotgo on GitHub](https://github.com/go-vgo/robotgo)
- [License: Apache-2.0](https://github.com/go-vgo/robotgo/blob/master/LICENSE)
- [Project website](https://atomai.cc)
- [README](https://github.com/go-vgo/robotgo/blob/master/README.md)
- [Releases](https://github.com/go-vgo/robotgo/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/go-vgo-robotgo