Greentic Desktop

Greentic Desktop helps teams turn repeatable desktop work into safe, reusable automation.

It is designed for situations where important work still happens inside desktop apps, web portals, terminal systems, Java applications, remote desktops, or legacy business tools. A Greentic Desktop "runner" describes that work once, checks that it is allowed, replays it on a compatible desktop, and keeps evidence of what happened.

What You Can Use It For

• Open an application or web page and complete a known task.
• Turn a demonstrated workflow into a reusable runner.
• Expose ready runners so an assistant or MCP client can call them.
• Run desktop tasks with inputs, secrets, approvals, and audit evidence.
• Use web automation today, with native desktop, terminal, Java, and screenshot-based paths clearly marked as experimental until their real fixture tests pass.
• Validate desktop environments before rolling out patches or updates.

Greentic Desktop is not a general-purpose screen macro recorder. It is a controlled runner system: every runner declares what it needs, what it can do, which adapters it uses, and what evidence should be kept.

How It Works

1. Set up the desktop runtime. The runtime creates a local Greentic Desktop home folder for runners, extensions, configuration, and evidence.
2. Install adapters. Adapters declare what Greentic Desktop can attempt. Check the Capability Matrix before assuming a path is production-ready.
3. Create a runner. A runner can come from a prompt, a human demonstration, or a mix of both.
4. Review and refine it. Corrections can update individual steps without requiring a user to hand-edit the runner package.
5. Approve and expose it. Ready runners can be exposed as MCP tools; production publishing/signing is modeled and still being completed.
6. Run it safely. Each call checks inputs, secrets, permissions, approvals, environment policy, and rate limits.
7. Keep evidence. Runs produce evidence references for audit, troubleshooting, and rollout decisions.

Your First Automation

The usual path is:

1. Record or describe the task once. Start from a clear, repeatable task such as "open a resource table, ask for resource_name, name, and email, append a row, save, and return saved_status." Greentic Desktop observes or plans the app target, inputs, commands, outputs, assertions, and evidence checks.
2. Turn it into a runner. The recording or prompt is normalized into a runner package. The runner keeps stable targets, typed inputs, required secrets, expected outputs, output extractors, assertions, and evidence rules.
3. Review and approve the runner. A person checks the runner before it is used by others. Published runners are expected to be signed so production systems do not run unapproved desktop automation.
4. Expose it as an MCP tool. The saved runner is the tool contract: stable name, input schema, output schema, permissions, approval policy, and evidence settings. A local MCP client can then call that tool instead of driving the desktop directly.
5. Use it from an assistant or workflow. The caller supplies the required inputs, Greentic Desktop replays the desktop task, and the response includes structured outputs plus an evidence reference.

The current CLI can initialize the runtime, install adapter manifests, plan draft runners from prompts, manage recording sessions, and discover local .gtpack runner packages. The usable MCP endpoint is currently the GUI-managed MCP service in Automate Hub. Web runner replay through MCP has a real fixture-backed path. Native desktop, terminal, Java, and vision adapters are experimental until their operating-system fixture suites prove recording, replay, output extraction, assertions, and evidence. See Capability Matrix, Getting Started, Recording and Refinement, Runners, and MCP Tools for the detailed workflow.

Open Greentic Desktop

Start the GUI-first experience with:

greentic-desktop

Automate Hub opens in the browser. From there you can complete setup, create from prompt, record a task, test and save runners, expose ready runners as MCP tools, and copy MCP client configuration for AI workers. See Automate Hub GUI for the full browser workflow.

Install Greentic Desktop

macOS / Linux

curl -fsSL https://raw.githubusercontent.com/greenticai/greentic-desktop/main/install.sh | sh

Windows PowerShell

irm https://raw.githubusercontent.com/greenticai/greentic-desktop/main/install.ps1 | iex

Then start Automate Hub:

greentic-desktop

Developer install with Rust remains available:

cargo binstall greentic-desktop

Manual release archive installation is also supported. See One-Line Install and Release And Installation.

Command-Line Entry Points

For Rust developers, install the CLI with cargo-binstall:

cargo binstall greentic-desktop

Windows users can also download the x86_64-pc-windows-msvc or aarch64-pc-windows-msvc zip from a GitHub release, extract it, and double-click greentic-desktop.exe to open Automate Hub. Public cargo binstall requires public crates.io metadata and publicly accessible release assets; private GitHub releases need an authenticated distribution path. See Release And Installation.

From this repository, greentic-desktop with no arguments starts the local Automate Hub GUI, opens the default browser, and serves the embedded frontend from a loopback address. The current CLI can also show runtime information, initialize local storage, manage built-in extensions, plan draft runners, manage recording sessions, and list local runner packages. Start, stop, or restart the usable MCP server from Automate Hub's My Runners screen.

greentic-desktop
greentic-desktop gui --no-open --bind 127.0.0.1:0
greentic-desktop info
greentic-desktop init
greentic-desktop extension install greentic.desktop.playwright
greentic-desktop extension list
greentic-desktop runner list
greentic-desktop runner plan --prompt "Open a resource table, ask for resource_name, name, and email, append a row, save, and return saved_status" --dry-run
greentic-desktop record start --name generic.resource_append --profile local-web --adapter greentic.desktop.playwright --out ./recordings/generic.resource_append

Detailed Documentation

• Getting Started
• One-Line Install
• Automate Hub GUI
• Runners
• Capability Matrix
• Adapters and Supported Desktops
  • Playwright Web Adapter
  • Terminal TN3270 Adapter
  • Windows UI Adapter
  • Java Accessibility Adapter
  • Vision Adapter
  • macOS Accessibility Adapter
  • Linux X11 Adapter
  • Linux Wayland Adapter
• Recording and Refinement
• Recording Runbooks
• MCP Tools
• Security, Approvals, and Secrets
• Evidence and Audit Trail
• Business Workflows
• Deployment and Rollout
• Release And Installation
• Extension Store
• Extension Package Format
• Extension GHCR Publish Pipeline
• End-To-End Smoke Checklist
• AWS WorkSpaces MCP Forwarding
• CLI Reference
• Developer Notes

What Is Implemented In This Repository

This repository contains the Rust workspace for Greentic Desktop. The current implementation includes:

• A runtime and CLI for local initialization, extension management, prompt planning, recording session lifecycle, runner discovery, replay, and MCP serving.
• Models for runner packages, portable desktop steps, replay validation, evidence, registry signing, security policy, deployment, rollout, and business flows.
• Built-in extension manifests for web, terminal, Windows UI Automation, Java accessibility, vision fallback, macOS accessibility, Linux X11, and Linux Wayland compatibility.
• Test coverage for the modeled workflows and local validation through CI.
• A beta web/MCP/evidence vertical slice with fixture coverage.

Some feature areas are implemented as domain models and tests rather than production-proven desktop automation. Native desktop, terminal, Java, and vision adapters must be treated as experimental unless the Capability Matrix says otherwise.

Execution Truthfulness

Runner execution is visible when the selected adapter drives a visible desktop, browser, Java app, terminal, or remote viewport in the current user session. Web and terminal adapters can also run in controlled contexts that do not mirror every click in an unrelated user tab or shell. Native desktop recording and replay require the operating system permissions and session access listed in the adapter docs; if those checks fail, Greentic Desktop should block with a concrete reason instead of claiming success.

Release validation must fail if product runtime paths fabricate outputs such as sample-output, use fixed company names, or pass without declared inputs, secrets, output extractors, and evidence.

Local Validation

For contributors, the main validation command is:

bash ci/local_check.sh

It runs formatting, linting, tests, builds, documentation generation, package checks, and publish dry-runs for publishable crates.