Put an agent on your phone: two routes, one red line

Treating a phone agent as a toy is easy; using one safely is not. A desktop agent that slips may delete a file; a phone agent that slips may send a WeChat message or tap a payment confirmation for you. This piece gives a decision framework, two routes, a pitfall table, and one red line.

Route A: OmniBot is an on-device app: install one APK and it runs inside the phone. Route B: OpenGUI is a framework reached through DeepSeek Harness. Compare with the site's Mobile GUI Agent Five-Way Comparison. This covers only installing and starting a phone-side agent, so it does not overlap with the site's Desktop Computer Use Build SOP, whose action space is the browser and local apps.

Decide First: Should You Run This on a Real Phone

One test decides it: if this device goes wrong, can you afford the loss?

A phone GUI agent holds far more authority than a desktop agent: it needs screenshots to "see" and cross-app tap injection to "operate", carried in OpenGUI through the Android AccessibilityService. One misjudgment exposes every logged-in account on that phone.

Fits a first run:

• You want to verify whether a phone agent can do real work, and you have a spare phone.
• Your work is repetitive with clear rules: bulk form filling, cross-app information gathering, regression testing, social media drafts.

Avoid on a real phone:

• Your primary phone. Exposing every account and message to a button-tapping program is a bad trade.
• Unattended long tasks. OpenGUI's README says that for long-running tasks, "reliability still needs more real-world testing."
• Payment, password changes, messaging, or account settings. Every route must keep a human confirmation step; OpenGUI lists "human confirmation before publishing, messaging, or account changes" as recommended, not optional.

Two Routes Compared

Take A to validate one thing on a phone; take B for an orchestration backend, which splits planning, execution, summarization, and retry into layers.

Route A, Steps 1 to 3: Install, Configure, Add Skills

Step 1: Install the APK. Download it from the Releases page (the README cites omnimind-ai/OpenOmniBot/releases). No minimum Android version is stated; treat the Release notes as authoritative.

git clone https://github.com/omnimind-ai/OpenOmniBot.git
cd OpenOmniBot
cd ui && flutter pub get

cd ..
./gradlew :app:installDevelopStandardDebug -Ptarget=lib/main_standard.dart

Build requirements per the README: Flutter SDK 3.47.2+, JDK 17+, Node.js 20.19+ or 22.12+, and pnpm 10.28.0 for WebUI.

Step 2: Configure the app (Settings, left sidebar). Order matters:

1. Configure AI capabilities.
2. Configure the AI provider (OpenAI-compatible: base URL, key, model name).
3. Open scenario model settings and assign a model per scenario.
4. The step people skip: Memory embedding requires an embedding model; without one, memory does not work. Other scenarios should use multimodal or vision models, since a phone agent must "see" the interface.
5. The Alpine environment usually initializes on startup; it is what lets a Linux toolchain run on a phone.

Step 3: Add skills. Send the skills repository link to the in-app assistant and let it install; the README recommends https://github.com/OpenMinis/MinisSkills. Then toggle skills in the skill repository.

Route A, Steps 4 to 6: Run Tasks and Two Optional Extensions

Step 4: Run a task. Scheduled tasks execute subagent flows; alarms are reminder-only. A subagent given a full task behaves like a full agent, and the app ships a Workspace, browser, and terminal.

Step 5 (optional): Remote Codex bridge. To let the phone use Codex on your computer, run this where the Codex CLI is installed and logged in:

npx @thuocean/codex-bridge

Choose the LAN address and token mode in the terminal UI, then scan the QR code from the app's Codex settings. This exposes your computer's execution capability to the phone: trusted LAN only, never a public binding.

Step 6 (optional): WebUI and local service. Open Settings > Local Service, enable it, and copy the address and Token. The default port is 8899; use the address the app shows.

cd webchat
pnpm install --frozen-lockfile
VITE_WEBCHAT_PROXY_TARGET=http://192.168.1.20:8899 pnpm dev

Two README pitfalls: do not append /webchat to the address, and use the port the app displays, not the sample from the docs.

Route B, Step 7: Wire OpenGUI into DSH (Get the Version Right)

Prerequisites, from the README's "Current Limitations": an Android 11 (API 30) or newer device or emulator; USB debugging plus the AccessibilityService permission; and for the DSH plugin route, macOS with Node.js 22.19+ or 24+.

Paste the README's installer prompt into Codex verbatim:

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.

The installer downloads the release package and checksum, verifies SHA-256, installs only the OpenGUI plugin, starts and opens DSH as needed, and preserves unrelated DSH plugins and settings. It reports whether it reloaded a managed DSH or whether you must quit an existing process and rerun. On Linux or Windows, use the manual package install in the plugin README.

Version discipline is where people trip:

DSH 0.1.0 RCs cannot read the credential store written by 0.1.1 RCs, so the installer refuses that downgrade before changing any files and recommends a separate DSH home. Existing installs, workspaces, model settings, and phone authorizations are preserved, so do not delete files to "try a downgrade."

Route B, Steps 8 to 9: Connect a Phone, Split Models by Role, Standby Dispatch

Step 8: Connect a real phone and run the first task. Select a DSH workspace, connect an authorized Android phone, then send:

@OpenGUI Open Settings and report the Android version

This read-only task proves the chain works; open write actions only after it passes.

Source-behavior note (the README says this is not a release claim): currently each DSH session admits only one OpenGUI task, non-conflicting phone sets can use separate tabs, and the managed browser is globally serial. Do not design around parallelism.

Step 9: Split models by role -- the cost lever.

• High-performance profile: the latest Claude Opus family across planning, supervision, review, and vision. Best quality, highest cost.
• Cost-saving mixed profile: Qwen 3.6 Plus for text-side roles (Planner, Supervisor), Doubao Pro for VLM execution.

Because planning and VLM execution can sit with different providers, "expensive model plans, cheap model executes" is a first-class option. The README says the mixed profile usually cuts cost to roughly one tenth to one fifteenth of an all-Opus setup. For GUI execution the recommended order is Doubao VLM, Qwen VLM, OpenAI vision models, then Grok vision models (still experimental). Pricing and policy vary by version and region; whichever provider you pick, the model must support both image input and tool calling. Related movement: Alibaba Qwen Intelligence Launch Hotspot.

Step 10 (optional): Standby dispatch. The backend ships Feishu / Telegram / Discord / REST API entry points and a standby dispatch path: keep the phone on a persistent standby connection to dispatch work remotely, with structured results returned to the backend.

Safety: One Red Line, Five Rules

One red line: publishing, sending messages, changing passwords, changing account settings, and any payment action must be confirmed by a human, every single time. Not "authorize once and let go" -- a checkpoint every time. Breaking it wipes out the value of every step above.

Five rules:

• Use a spare phone, not your primary one, and isolate accounts where you can.
• Grant only necessary permissions. Avoid accessibility if you can; before granting it, think through what it can see.
• LAN and allowlists: run the bridge and local service only on a trusted LAN. Tokens stay put -- not in chats, not in screenshots, not in repositories.
• Logs and audit: keep an operation record. OpenGUI's Summarizer produces structured results usable as an audit basis.
• Short tasks before long tasks: start with read-only actions, then open up write actions gradually.

Pre-Launch Checklist and Pitfall Table

• The device is a spare phone, with accounts isolated as far as practical
• Only necessary permissions are granted; accessibility is not granted casually
• Payment / messaging / password / account-setting actions require per-action human confirmation
• The bridge and local service run only on a trusted LAN, and tokens have not leaked
• Operation logging is on and traceable
• A read-only short task validated the chain before write actions opened up
• The tool's license matches your use case

Pitfall quick reference, with mitigations:

The first three rows apply to Route B, the middle two to Route A, the last two to both.

License Boundaries: Read It Before Company Workflows

OmniBot uses segmented dual licensing. The open-source side is GNU AGPL v3, free only for non-commercial use or personal, educational, or research purposes, and the license text prohibits use by any organization, putting organizations outside the free scope even for research. Commercial use requires a commercial license signed with the maintainer in advance; so does avoiding AGPL v3's source-disclosure obligation. Do not compress this into "an AGPL open source project" or "free for commercial use." For repository data, see the site's OmniBot Open-Source On-Device Agent.

OpenGUI is BSL 1.1 (Business Source License). The source is visible; you may copy, modify, distribute, and use it for non-production purposes; production use, commercial use, hosted services, and integration into commercial products require a separate commercial license from the maintainer. It is public source, but not OSI-approved open source until the Change Date.

Read the license before wiring either tool into a company workflow. For personal validation on a spare phone both routes work; once company business or commercial benefit is involved, check the license text first.

FAQ

Q1: I only have my primary phone. Can I still run this? Technically yes, but not advisable: a phone agent holds accessibility plus cross-app operation, so one misjudgment covers every account on the device. If you insist, start with read-only short tasks plus per-action confirmation.

Q2: I configured a model, so why can the agent still not "see" the interface? You likely configured a plain text LLM. A phone GUI agent's input is screenshots, so it needs a vision-capable (multimodal / VLM) model.

Q3: Is Memory embedding really mandatory? Yes. The OmniBot README states that Memory embedding needs an embedding model; without it the memory feature is unavailable.

Q4: Can I downgrade DSH to the older version I am used to? No, not from 0.1.1 RC down to 0.1.0 RC: 0.1.0 RCs cannot read the credential store written by 0.1.1 RCs, so the installer refuses before changing any files and recommends a separate DSH home. Pin a supported version with --dsh-version instead.

Q5: Can it run a phone task and a browser task at the same time? Not under the current source: the README states that each DSH session admits only one OpenGUI task and that the managed browser is globally serial, adding that "this source behavior is not a release claim."

Sources

• OmniBot repository README and Releases (omnimind-ai/OpenOmniBot): installation, configuration, Skills, scheduled tasks, Remote Codex bridge, WebUI service; collected 2026-09-23.
• OpenGUI repository README and Releases (Core-Mate/OpenGUI): DSH plugin install, supported versions and downgrade policy, first-task example, model profiles, standby dispatch, limitations, license; collected 2026-09-23.
• DeepSeek Harness plugin docs (deepseek-harness-plugin/README.md, docs/): installer behavior, manual package paths, use cases; collected 2026-09-23.
• Licenses follow each repo's root LICENSE: OmniBot is segmented dual licensing (AGPL v3 plus commercial); OpenGUI is BSL 1.1.
• AI Cake: Mobile GUI Agent Five-Way Comparison, OmniBot Open-Source On-Device Agent, and Desktop Computer Use Build SOP.
• Pricing or quota not stated officially is deliberately omitted; the official sources are authoritative.