# OmniBot: an on-device Android AI agent that runs a terminal, a browser and scheduled subagents

> OmniBot is a Flutter and native Kotlin Android app that combines chat with an Alpine environment, a workspace, browser access and MCP tools. It is aimed at people who want agent actions to happen on the phone rather than in a cloud sandbox, and its Codex bridge lets a desktop CLI drive the same app over the LAN.

**omnimind-ai/OmniBot** — Your on-phone / mobile AI Agent / Claw, capable of operating terminals and performing a wide range of tasks in the Android world || 你的手机 AI 代理，她可以操作终端，也可以完成 Android 世界的广泛任务 

- Repository: https://github.com/omnimind-ai/OmniBot
- Website: https://omnibot.omnimind.com.cn
- Stars: 2,017 · Forks: 145
- Language: Dart
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/omnimind-ai-omnibot

## What OmniBot actually does that a chat app does not

Most phone AI apps stop at conversation. OmniBot's README states the project focuses on the full loop of understand, decide, execute and reflect, and the repository layout backs that up: there are top-level directories for skills, plugins, tools, accessibility, androidgui and a webchat frontend, alongside an omniflow-android module. The intended user is someone who wants the phone itself to be the execution surface. The README lists system-level actions such as scheduled tasks, alarms, calendar creation, query and update, and audio playback control, plus productivity tools for reading and writing files, browsing the workspace, using a browser and accessing a terminal. That combination is the point. A cloud agent can write a file in a container; OmniBot's claim is that it can touch the device it is running on. The trade-off is that the same capability makes permission scope the central question, and the README does not document a permission model or a sandbox boundary around those system actions.

## How the Alpine environment, skills and subagents fit together

The architecture visible in the repository is layered. A Flutter UI (the ui/ directory) sits over native Android Kotlin code, with baselib, uikit and app modules in the tree. The README says the app usually initializes the Alpine environment automatically on startup and that the environment can also be managed from the settings area, so the terminal tools are not a separate download. Skills are the extension point: the README says you can ask OmniBot to install a skill by sending it a repository link, and points to a recommended collection at https://github.com/OpenMinis/MinisSkills. Enablement happens from a skill repository screen. Scheduled tasks are a second execution path, and the README draws a distinction worth noting: scheduled tasks execute subagent flows, alarms are reminder-only, and a subagent can be assigned a complete task and behaves like a full agent. Memory is split into short-term and long-term with embedding support, and the README warns that memory embedding requires an embedding model while other scenarios should use multimodal or vision-capable models. That is a configuration dependency, not a detail: without an embedding model the long-term memory path is not usable as described.

## Installing OmniBot and configuring a first task

The README does not give an APK download URL or a store listing. It points to the releases page at https://github.com/omnimind-ai/OpenOmniBot/releases, so that is where a build comes from. If you want to build it yourself, the development guide lists the requirements and the first commands. Flutter SDK 3.9.2+ and JDK 11+ are required, and Node.js 20.19+ or 22.12+ with pnpm 10.28.0 is needed only for WebUI work.

```bash
git clone https://github.com/omnimind-ai/OpenOmniBot.git
cd OpenOmniBot

cd ui
flutter pub get
```

If Flutter reports that it cannot read the include_flutter.groovy script under ui/.android, the README's remedy is a clean and a re-fetch:

```bash
flutter clean
flutter pub get
```

Once the app is running, the first real task is configuration, not conversation. Open the settings page from the left sidebar and set up AI providers, then open the scenario model settings. The README notes that memory embedding needs an embedding model and that the other scenarios should use multimodal or vision-capable models where possible. After that, the Alpine environment usually initializes on startup and can be managed from the same settings area. A reasonable first use is to send the app a skill repository link, which the README describes as the way to install a skill, and then check the skill store screen to enable or disable it.

## The Codex bridge and the WebUI development proxy

Two pieces of the project assume a second machine. The first is Codex mode. If you run the Codex CLI on a PC or Mac, the README says to start the bridge on that computer where Codex is installed and logged in:

```bash
npx @thuocean/codex-bridge
```

You then choose the LAN address and token mode in the terminal setup UI and scan the printed QR code from OpenOmniBot's Codex settings. The second is WebUI development. The webchat/ directory is a standalone React, TypeScript and Vite project, and during local development Vite proxies /webchat/api to the Android app's local service. The README's steps are to enable the local service in Settings, copy its address and token, and start the dev server with the proxy target set. The default port is 8899, but the README says to always use the address shown by the app, and not to append /webchat to it.

```bash
cd webchat
pnpm install --frozen-lockfile

VITE_WEBCHAT_PROXY_TARGET=http://192.168.1.20:8899 pnpm dev
```

On PowerShell the variable is set first with $env:VITE_WEBCHAT_PROXY_TARGET. The README notes that pnpm dev is the mode to use for end-to-end API and SSE testing, because the proxy keeps session cookies, realtime events, workspace access and browser mirroring on the same local origin. For Android builds, Gradle handles the WebUI automatically: it runs the locked pnpm install, runs the Vite production build, clears stale WebChat assets and copies only dist/ into the APK. Flutter Web is explicitly not part of this workflow, which is a useful boundary if you assumed the webchat frontend was a Flutter target.

## Where OmniBot is the wrong tool

The documentation is thin in exactly the places that matter for adoption. There is no documented permission model for the system-level actions, no description of what the agent can reach through the accessibility APIs, and no stated sandbox boundary around the Alpine environment beyond the fact that it exists and initializes on startup. If your requirement is that an agent must be provably unable to read a calendar or send an alarm, the README does not give you the evidence to conclude that. The licence is a second open question: the repository metadata reports NOASSERTION, so the LICENSE file in the root is the thing to read rather than any summary. Third, this is not a library. Dart is the primary language and the app is the product; there is no documented public API for embedding OmniBot in another Android app, and the WebUI talks to a local service over the LAN rather than to a published SDK. If you need a stable, versioned API surface, a chat app with a documented function-calling interface is a better fit. Finally, the release cadence is fast: v0.6.2.1, v0.6.2.2 and v0.6.2.3 all landed between 2026-09-08 and 2026-09-10, with one release note describing a Codex plan and confirmation recovery fix. That pattern suggests active work, and it also suggests you should expect to upgrade to get fixes.

## A real alternative and the difference in approach

Tasker is the closest comparison for the Android automation half of this project, and the difference is in who writes the logic. Tasker asks you to define profiles, tasks and conditions yourself: you decide the trigger and the action graph, and the automation runs deterministically. OmniBot inverts that. You describe an outcome in chat, and a model decides which tools to call, with skills, Alpine commands, browser access and MCP as the tool surface, and subagents as the unit of scheduled work. The cost of the inversion is predictability. A Tasker profile that fails fails the same way every time; an agent that misreads a request can call a different tool. The benefit is coverage: the README's examples include installing a skill by pasting a repository link, which is not something you configure in a rule engine. If your workflows are fixed and you want them auditable line by line, Tasker-style automation is the safer choice. If your workflows vary and you want a model to pick the steps, OmniBot is built for that, and the Codex bridge extends the same pattern to a desktop CLI you already have logged in.

## Maintenance cost, licensing and what to check before you commit

The repository is not archived, and the last push was on 2026-09-10, so the project is being worked on now. That cuts both ways for cost. You are not adopting a frozen artifact, but you are also adopting something whose release notes include recovery fixes for a planning flow, which means behaviour can change between point releases. Budget for reading release notes before upgrading rather than treating upgrades as routine. The licence identifier in the repository metadata is NOASSERTION, which is not a licence. It means the automated detection could not classify the LICENSE file. Read that file directly and decide whether its terms fit how you intend to distribute or modify the app; this is not legal advice and the file is the only authority. On the build side, the toolchain requirements are specific: Flutter 3.9.2+ and JDK 11+ for the app, Node.js 20.19+ or 22.12+ with pnpm 10.28.0 for WebUI work, and note that node_modules/ and webchat/dist/ are local outputs that the README says must not be committed. The Codex bridge is a separate npm package, so its maintenance is not tied to the app's release cadence.

## Conclusion

Adopt OmniBot if you want an agent that acts on the phone itself: terminal commands in an Alpine environment, a workspace, browser access, scheduled subagent runs, and an optional Codex bridge from a desktop CLI over the LAN. Skip it if you need a documented, audited security model before granting an app system-level calendar, alarm and audio control, or if you want a stable public API rather than a project that shipped three releases in the week before 2026-09-10. Before installing, verify the LICENSE file in the repository root, since the project metadata reports NOASSERTION, and check whether the Codex bridge fits your threat model, because it exposes a LAN address and a token to the app.

## FAQ

### What is OmniBot?

It is an on-device AI agent for Android, built with native Kotlin and Flutter, that combines chat with agent tools, local workspaces and system integrations. The README describes it as covering the loop of understand, decide, execute and reflect, with skills, an Alpine environment, browser access, MCP and Android system-level tools as the tool surface.

### How do you program OmniBot?

You do not write a program in the usual sense. You configure model providers and scenario models in settings, then install skills by sending the app a repository link, enable or disable them from the skill repository screen, and describe tasks in chat. Scheduled tasks run subagent flows, while alarms are reminder-only.

### What does OmniBot mean?

The repository does not give an etymology. The project is named omnimind-ai/OmniBot and its README titles it OpenOmniBot, describing it as an on-device AI assistant for Android.

## Sources

- [Issues](https://github.com/omnimind-ai/OmniBot/issues)
- [omnimind-ai/OmniBot on GitHub](https://github.com/omnimind-ai/OmniBot)
- [Project website](https://omnibot.omnimind.com.cn)
- [README](https://github.com/omnimind-ai/OmniBot/blob/main/README.md)
- [Releases](https://github.com/omnimind-ai/OmniBot/releases)

---

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