# OpenPocket drives Android over ADB while the model runs on your machine

> OpenPocket is a TypeScript framework that lets AI agents operate an Android emulator or an authorized physical phone through ADB. The interesting part is not the phone automation itself but the shape of the runtime: two npm-installed binaries, a config file, and per-agent isolation.

**pockebot/openpocket** — 🐹 An Intelligent Phone That Never Sleeps.

- Repository: https://github.com/pockebot/openpocket
- Website: https://openpocket.ai
- Stars: 850 · Forks: 6
- Language: JavaScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/pockebot-openpocket

## A second phone that agents drive through ADB

OpenPocket is a framework for letting language model agents operate an Android phone. The intent is a second device that works around the clock, replying to messages, paying bills, playing games, posting to social networks, while your own phone stays untouched. The mechanism is comparatively unglamorous: the agent talks to a phone over the Android Debug Bridge, and it produces the same input a person would, taps, swipes, text entry, navigation between apps.

That last part is what makes it different from a cloud phone automation service. There is no hosted device farm to rent. The targets are either Android emulators on your machine or physical phones you connect over ADB, and the project documentation states the agent phone and your personal phone are completely isolated, with sensitive actions requiring explicit human approval.

The project is written in TypeScript and packaged for Node.js 20 and newer. The package.json declares the module type as ES modules, the build as a plain tsc compile over tsconfig.json, and it ships two command line entry points, dist/cli.js as openpocket and dist/mcp/server.js as openpocket-mcp. That second binary matters more than it first appears, because it is the bridge to editor based agents.

The audience is developers who want a phone agent to run on infrastructure they control, with the model calls routed to whichever provider they choose.

## The two binaries and the config file are the whole product surface

There is no daemon to provision and no cluster to schedule. The npm package exposes one CLI with subcommands. Onboarding is its own step, which suggests it writes a configuration and prepares credentials rather than merely printing help.

```bash
npm install -g openpocket
openpocket onboard
```

The repository ships openpocket.config.example.json at the top level, and the published file list in package.json includes it, so the example is intended to be copied and edited. Everything the runtime needs, model providers, device targets, channel bindings, is described by that file rather than by environment variables that the docs never mention.

After onboarding, the long running piece is a gateway. It exists because OpenPocket supports scheduled work, created as cron tasks from chat or from the CLI in natural language, and because results have to be pushed back to you through Telegram, Discord, WhatsApp, or the CLI. A one-off command that runs a single task and exits is a separate path, and it is documented as the agent subcommand.

```bash
openpocket gateway start
```

```bash
openpocket agent --model gpt-5.2-codex "Open Chrome and search weather"
```

The model flag shows the provider choice is per invocation rather than fixed at install time, which is the practical meaning of the multi-model claim in the highlights list.

## Approval for payments, camera and location travels over a local relay

The privacy story is not only about where the code runs. It is about what happens when an agent wants to do something consequential. The highlights list names three categories that escalate to a human: camera, payments, and location. Those escalations are delivered through a private local relay rather than through a hosted service, so the approval request and the agent session stay on the same machine.

This is a design decision with visible consequences. An agent that can tap a Pay button without a human in the loop is a different risk class from one that queues a request and waits. The cost of that safety is latency and the need to have a second channel open to approve requests, since an approval you cannot see is an approval that never arrives.

The published docs do not explain how the relay is configured, what happens to a pending approval when the gateway is stopped, or whether approvals can be pre-granted for a class of action. If your workflow depends on unattended operation, that is the first thing to check in the configuration guide.

Channel integrations are the other half of the same idea. Telegram, Discord, WhatsApp, and CLI are listed as ways to receive tasks and results, which is what turns the runtime from a developer tool into something you can drive from a phone, ironically, since your personal phone stays out of the automation path.

## One SKILL.md file adds a capability without a code change

Extension happens through a skills directory. The documentation says you extend agent capabilities by dropping a SKILL.md file into that directory, and the repository has a skills folder at the top level. The framing is that a capability is a document describing what the agent may do, not a compiled plugin, so adding or removing behaviour is a text file operation.

The same idea scales up into the Codex and Claude Code integration. The documentation describes one phone use integration with native adapters for both hosts, generated from the same phone-use skill and a 23-tool Android MCP source, so the host controls a device through ADB rather than through desktop Computer Use. The package.json declares a second binary, openpocket-mcp, and the dependencies include the Model Context Protocol SDK, which is the mechanism that exposes those 23 tools to an external host.

Installation of the native plugins is scripted, and one command covers dependencies, target setup, plugin installation, and what the docs call a 23-tool Doctor check.

```bash
npm run phone-use:install -- codex --target emulator
npm run phone-use:install -- claude-code --target emulator
```

The docs state that the two host directories are thin install roots rather than separate implementations, and that their generated skills and runtimes are kept identical by a single packaging command plus automated tests. That is the right way to avoid the classic drift where a Codex adapter and a Claude Code adapter slowly diverge, and it is the reason the plugin directories are listed separately in the repository but share one source.

## Emulator first, physical phone second, and the target flag decides

Target selection is a first class concept rather than a runtime detail. The phone-use install command takes a target argument, and the examples pass emulator. The docs name two target kinds, Android emulators and physical phones reachable over ADB, and it mentions running multiple agents against multiple targets, which it frames as building your own local phone farm.

The multi-agent design is worth pausing on. The highlights list says each agent gets its own config, workspace, target device, and session state, and that the agents are isolated from each other. Isolation is what makes parallel agents against parallel devices workable at all, because two agents sharing a device would interleave taps and produce garbage. A config, workspace, and session per agent is a heavier design than a shared queue, and it is the right trade-off for the stated use case.

A physical device raises the question the project does not answer: the documentation describes the personal phone and the agent phone as isolated, and sensitive actions as approval gated, but it does not publish a threat model for a real device that sits on your desk, left idle, with a debug bridge attached. Emulator targets keep the blast radius inside a sandbox you can throw away. For a first run, the emulator is the cheaper place to learn the CLI and the approval flow.

## The npm release is a single 0.2.3 version with no GitHub releases behind it

Version and maintenance are the two weakest points of this project as a dependency. The package.json reports version 0.2.3, and the repository has no GitHub releases at all, so there is no changelog to read on the release page and no tag to diff against. The last push to the repository was on 2026-07-09, and the project is not archived, so the code is moving without a published version history.

The dependency surface is worth counting. Alongside the agent core packages and the Model Context Protocol SDK, the dependency list includes the Slack Bolt SDK, the Slack web API, baileys, and qrcode types, which points to channel handling and QR based pairing rather than a minimal core. A package that reaches for chat transport, device control, model providers, and a scheduler in one install carries a larger upgrade surface than its problem statement suggests. Since there are no release tags, upgrading means diffing the npm package versions yourself.

Two details in the packaging metadata deserve attention. The repository URL in package.json points at github.com/SergioChan/openpocket rather than the pockebot organisation, so the canonical source for the published artifact is not the repository you are probably looking at. And the LICENSE is MIT, which is the permissive choice most teams want, though the MIT terms themselves are worth reading before you embed the runtime in a commercial product.

The build is plain and reproducible. Compiling is a tsc project, type checking without emit is a separate script, and the test command compiles first and then runs the node test runner over the test directory.

## Where OpenPocket is the wrong tool

Three situations rule it out. If you need hardened, audited, multi-tenant device automation, this is not it. The isolation is between agents in your own workspace, and the approval relay is local. A hosted platform with a compliance story is a different category of product.

If your goal is simply to script an Android app, a shell script over adb with a few uiautomator dumps will be far cheaper to maintain than a model in the loop. Agents are for tasks where the steps are not known in advance.

If you cannot keep a gateway running on a machine that is awake and reachable, the scheduler and channel features are dead weight. The cron style tasks assume a process that is up when the task fires.

The honest limitation is elsewhere. The repository is young, the version number is low, and the published artefact points at a different repository than the one holding the source you would read. The technical design is sound, but the operational surface of an always-on phone agent with payment approvals is larger than the published docs make obvious, and the failure modes of that surface are not written down anywhere in the documentation.

## Conclusion

Adopt OpenPocket if you want local, approval-gated phone automation and you are comfortable with a runtime that ships a gateway, a cron scheduler, chat integrations and a 23-tool MCP surface in one package. Skip it if you need a hardened production device fleet or a stable release cadence, because the repository has no GitHub releases and the last push was on 2026-07-09. Before installing, read openpocket.config.example.json and confirm that the ADB target you attach is a device you are authorised to automate, since the entire approval and isolation model depends on that choice.

## FAQ

### How do I install OpenPocket and run my first agent task?

The docs give npm install -g openpocket followed by openpocket onboard, then openpocket agent --model gpt-5.2-codex "Open Chrome and search weather" for a one-off task. Node.js 20 or newer is required, and the source path is git clone, npm install, npm run build, then ./openpocket onboard.

### What is the openpocket-mcp binary and what does it do?

The package.json registers two entry points, openpocket pointing at dist/cli.js and openpocket-mcp pointing at dist/mcp/server.js. The phone use integration for Codex and Claude Code is described as a 23-tool Android MCP source, which is what the MCP server exposes to those hosts.

### Does OpenPocket need human approval before an agent makes a payment?

The documentation states that sensitive actions, including camera, payments and location, escalate for approval through a private local relay, and that the agent phone is isolated from your personal phone. How the relay is configured is left to the configuration guide.

## Sources

- [Issues](https://github.com/pockebot/openpocket/issues)
- [License: MIT](https://github.com/pockebot/openpocket/blob/main/LICENSE)
- [pockebot/openpocket on GitHub](https://github.com/pockebot/openpocket)
- [Project website](https://openpocket.ai)
- [README](https://github.com/pockebot/openpocket/blob/main/README.md)

---

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