OpenGUI: one Android GUI agent framework behind two very different connectors

Two connectors with two different install contracts

OpenGUI is one framework with two front doors, and the difference between them is larger than a plugin choice.

The DeepSeek Harness path adds phone and browser operation to DSH without requiring the full OpenGUI backend stack. It needs a Node.js runtime, a supported DSH version, a workspace, and an authorized phone selected inside DSH. The WorkBuddy path needs none of that: it is an MCP server, a Skill and lifecycle Hooks installed into WorkBuddy, and it uses WorkBuddy's own current visual model, so there is no DSH installation, no full OpenGUI backend and no extra model API key. It opens read-only scrcpy windows by default.

The repository structure backs this up. Alongside client/, server/, plugins/, skills/ and docs/ there are two connector directories, deepseek-harness-plugin/ and workbuddy-plugin/, each with its own README and its own versioning story. A framework that had picked one host would not need a directory per host.

The release history shows the asymmetry. The three most recent tags are opengui-workbuddy-v0.2.0 on 2026-09-07, opengui-workbuddy-v0.3.0 on 2026-09-16 and opengui-workbuddy-v0.3.1 on 2026-09-16, all of them WorkBuddy packages. The DeepSeek Harness path is not versioned through the same tags at all; the README links a separate release page, the v0.1.13 release package tagged dsh-coremate-mobile-v0.1.13. So the two connectors are versioned on different trains, and the one with the smaller version number is not necessarily the older one.

That matters when you read a release note. A WorkBuddy bump tells you nothing about the DSH plugin, and a DSH package version tells you nothing about the MCP.

The DSH version matrix, and an installer that refuses to downgrade

The DeepSeek Harness integration is fussy about versions, and the fussiness is documented to a degree that is worth reading twice.

OpenGUI supports DSH 0.1.0-rc.7, 0.1.0-rc.8, 0.1.1-rc.1 and 0.1.1-rc.2, and new installs default to 0.1.1-rc.2. DSH 0.1.2-alpha.4 is explicitly not supported. The macOS installer reuses a PATH runtime only when it exactly matches the selected version, and otherwise installs an isolated managed runtime under the OpenGUI DSH home, so a machine with an unrelated DSH on PATH does not get it commandeered. You can pick a supported version with --dsh-version VERSION.

The most interesting sentence is about credentials. DSH 0.1.0 release candidates cannot read the versioned credential store written by DSH 0.1.1 release candidates, so the installer refuses that state downgrade before changing any files, and recommends a separate DSH home. Read that as an engineering decision rather than a formality: the failure mode being avoided is a half-migrated credential store, which is the kind of problem that surfaces days later as a re-authentication loop with no obvious cause. Refusing before touching the filesystem is the right order of operations, and the documentation says so plainly enough that a reader can predict what the installer will do in the state they are actually in.

The installer also promises that existing DSH installations, workspaces, model settings, credentials and phone authorizations are preserved, and that it installs only the OpenGUI plugin while leaving unrelated plugins and settings alone. After installing, you add or select a DSH workspace, connect and select an authorized Android phone, and then send the first task. What the README does not give you is a rollback procedure, so the mention of an explicit version remaining available for rollback is the only guidance on going back.

One task per session, and a browser that is globally serial

The sharpest limitation in the project is written in the README in a form most projects would have edited out.

The current source implementation admits one OpenGUI task per DSH session, and separate tabs on non-conflicting phone sets. The managed browser remains globally serial. And then the qualifier: this source behavior is not a release claim.

That last clause deserves attention on its own. The author is stating that the code today has these properties, while declining to promise them in a versioned artifact. For a framework whose whole value is unattended operation, a concurrency ceiling of one task per session is not a footnote. It means throughput is bounded by how long a single phone task takes, and it means the usual instinct, open four tabs and run four devices, works only when the phone sets do not conflict. Whether two devices holding the same account or the same app count as conflicting is not stated.

The browser being globally serial is the sharper edge of the two. A single managed browser resource shared across all sessions means any task that drives a browser blocks every other task that wants one, regardless of phone. For a regression suite that mostly exercises the phone, that is fine. For anything mixing mobile and web verification, the browser is the queue.

The disclaimer is arguably over-cautious. It is also the reason you should verify the behaviour against a build you are actually running rather than against a README sentence, since the sentence is explicitly disowned by the release process.

Installing a GUI agent by pasting a prompt into an agent

The recommended path on macOS is to hand the installation to Codex. You paste one prompt, and the installer Skill resolves the latest stable OpenGUI plugin release, verifies it, installs it into DSH and opens DSH. The README's own prompt is:

Install and run the OpenGUI installer Skill from https://github.com/Core-Mate/OpenGUI/tree/main/deepseek-harness-plugin/skills/opengui-coremate-install for my DSH web profile. Install the latest stable release. Proceed autonomously, and only pause when I need to authorize or select a phone, add or select a DSH workspace, or provide fallback visual-model credentials.

An agent installing an agent deserves scepticism, so the specific mitigations matter. The Skill downloads the public release package and a checksum, verifies SHA-256, installs only the OpenGUI plugin, and preserves unrelated DSH plugins and settings. It reports whether it reloaded a managed DSH or whether you need to quit the running process and rerun. The runtime requirement is Node.js 22.19+ or 24+, and the compatible DSH version is installed automatically.

Two limits on the convenience. First, macOS only. The README says Linux and Windows users should follow the manual package guide instead, so the automated path is a first-class experience on one platform and a documented manual task on the others. Second, the prompt itself asks for pauses at exactly the right points: authorizing a phone, selecting a workspace, and supplying fallback visual-model credentials. The credential pause in particular is the project telling you that a fallback model path exists and will be requested, rather than something you discover after a failure.

The first real use, after a workspace and a phone are selected, is a single line:

@OpenGUI Open Settings and report the Android version

A request that produces a version number rather than a screenshot is a good first test, because it exercises the full loop and produces output you can check against the device in your hand.

Screenshots leave the device, and the model choice decides where

One sentence in the README covers the privacy question, and it is easy to skim past: phone tasks send screenshots to the selected model.

Every frame of every operation leaves the device and arrives at a third-party vision service. That is inherent to the approach rather than a flaw in this implementation, but it means the model table is a data-routing decision and not just a quality ranking. The table ranks Doubao VLM first for visual GUI execution, Qwen VLM second with the caveat that some social media prompts may be more sensitive to model safety policies, OpenAI vision-capable models third as the higher-cost option for screenshot-heavy tasks, and Grok vision-capable models fourth as experimental for this workflow, with tool use and action reliability still needing more validation.

The README adds that availability, pricing and policy behavior vary by version and region, and that whichever provider you pick must support both image input and tool calling. That last requirement is the hard one, and it is worth checking before installing anything: a model without tool calling cannot drive a GUI agent, and a model without image input cannot see the screen. The prerequisite is stated plainly, which is more than most projects manage.

The privacy consequence is not a reason to reject the framework, but it changes what the framework is. This is a tool for authorized devices where the screen contents are not sensitive, and where the person operating it is watching. The listed good fits are consistent with that reading: automated UI operation and regression testing on authorized devices, social media management and lead research with human confirmation before publishing, messaging or account changes, and repetitive game testing where the account owner and game rules permit automation. The human confirmation requirement in that middle example is stated as a property of the use case, not as an enforced gate in the code, and the README does not claim otherwise.

A custom licence under an agent-driven install path

The licence field on this repository reads Other, with the note that it is a custom licence GitHub cannot classify and that the LICENSE file is the reference. A LICENSE file is present at the root.

This deserves attention because of how the project is installed. The recommended path is a prompt that another agent executes, which fetches a package, verifies a checksum, writes into a managed runtime directory and launches an application. Handing an agent the authority to run code on your machine is normal in 2026 tooling, and the SHA-256 check is the right mitigation. But a custom licence is not an SPDX identifier, so no automated tool in your pipeline can tell you whether the terms match what your legal review approved, and a GitHub classifier declining to categorise it is a signal that the text is not a lightly edited standard licence.

Nothing here suggests the terms are unfavourable, and this is not a judgement about them; the LICENSE file has to be read directly. The point is procedural. A framework you install by asking an agent to install it, whose main asset is an accessibility-driven agent acting on a real device, is exactly the case where you would want a recognisable licence, and you do not get one from the metadata.

The repository is otherwise conventionally organised, with a CHANGELOG.md, CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md and AGENTS.md at the root alongside a .agents directory, so the missing piece is specifically the licence's recognisability. The homepage is opengui.ai, and the release packages are distributed from GitHub releases rather than from that site.

The WorkBuddy connector installs an MCP, a Skill and Hooks

The second connector is the simpler installation and the one with the more recent release history.

It installs three things together: an MCP server, a Skill named opengui, and lifecycle Hooks. It backs up the affected WorkBuddy configuration before changing it, and it preserves other plugins. WorkBuddy 5.5.6 and newer support the live installation flow, while older but compatible versions fall back to a Command-Q restart that preflight reports. Version 0.3.1 is described precisely: a macOS public-testing prerelease, not marketplace approval and not complete real-device acceptance. That is an unusually clear statement of what a version number does not mean.

The post-install steps are a checklist worth following in order, because each one is a trust decision rather than a keystroke. Enable or trust the opengui MCP if prompted, review the external Hook change in /hooks, confirm opengui in /skills, connect a USB-debugging-authorized Android phone, and select /opengui. The review step is the one to not skip. A Hook runs code at lifecycle events, and an MCP server has standing access to whatever tool calls the host makes on its behalf. Reading the change in /hooks before enabling it costs a minute.

Read-only scrcpy windows are opened by default, which is a sensible default for a first run: you can watch what the agent sees without being able to interfere through the same window. Whether the agent has write access to the device at all, and how that is gated, is not something the README excerpt spells out.

The first task through this path is the same test as the other one:

Open Settings and report the Android version on my phone.

Same request, two connectors, no shared version number. If you evaluate OpenGUI, evaluate the connector you would actually deploy, because the DSH and WorkBuddy paths differ in host, model provider, installation privilege and release cadence.

Editorial conclusion

Adopt OpenGUI if you have USB-debugging-authorized Android devices and a real need for authorized UI operation, and if you will accept that every screenshot of every screen reaches a third-party vision model. Do not adopt it for parallel device fleets, batch account workflows, or anything where a single serial task per session becomes the bottleneck, and do not adopt it on the strength of a licence summary, because the repository is classified as Other with a custom LICENSE file and GitHub could not classify it. Verify four things. Read the LICENSE file, since the install path invites an agent to fetch and run code on your machine and the terms are not an OSI identifier you can recognise at a glance. Confirm which connector you actually need, because the three most recent release tags are all WorkBuddy packages while the DeepSeek Harness path ships a separately versioned v0.1.13. Check your Node.js version against the 22.19+ or 24+ requirement, and know that DSH 0.1.2-alpha.4 is unsupported while four 0.1.0 and 0.1.1 release candidates are. Then run the first task on a device with nothing on it. The deciding constraint is that OpenGUI currently runs one task per session, so it is a tool for supervised automation on a device you are watching, not for unattended work at volume.

Frequently asked questions

Official sources

1. Core-Mate/OpenGUI on GitHub
2. Issues
3. Project website
4. README
5. Releases