# PalmClaw keeps the agent loop on the phone and the model in the cloud

> PalmClaw is an agent framework for Android, written in Kotlin and published alongside a paper accepted to the EMNLP 2026 system demonstrations track. The interesting architectural line is that everything about the agent, the sessions, the memory, the skills, the tools and the loop itself, runs on the device, while the model inference comes from an LLM API you configure yourself.

**ModalityDance/PalmClaw** — [EMNLP 2026 Demo] "PalmClaw: A Native On-Device Agent Framework for Mobile Phones"

- Repository: https://github.com/ModalityDance/PalmClaw
- Website: https://modalitydance.github.io/PalmClaw/
- Stars: 1,171 · Forks: 102
- Language: Kotlin
- License: AGPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/modalitydance-palmclaw

## The framework is the phone's, not the cloud's

PalmClaw is described as an open source agent framework inspired by OpenClaw and built to run directly on Android phones without a separate PC. The overview is specific about the split. It keeps sessions, context management, memory, skills, tools and the agent loop on the device, while model inference comes from a user configured LLM API. That is the whole design in one sentence, and it is the opposite of the usual arrangement where an agent backend holds the conversation and the phone is a thin client. The consequences are visible in the feature list. The app is where you run and configure the agent, the device capabilities are reached through structured device tools, and the actions are kept under control through schemas, permissions, confirmations and workspace boundaries. The project page is hosted separately, the paper is on arXiv, and the README links an APK download from the releases page, so the intended first contact with the project is to install it on a phone rather than to read the source.

## Structured device tools instead of a general shell

The second key feature is the tool layer, and its framing is what separates this from a script runner. The device capabilities, files, personal data, hardware, web, communication and automation, are reached through typed operations and structured results, rather than through a free-form command interface. That is a meaningful design choice on a phone, because a general shell on an Android device is a liability, while a typed operation with a schema is something the platform can check. The tools come in two flavours according to the release notes, with v0.3.1 describing expanded workspace files and native tools, and the roadmap records a visual tool management page as done, which suggests the tool set is browsable from the app rather than hidden in configuration. The third key feature is the execution boundary, and the documentation is unusually explicit that the checks happen before device actions are executed, which is the correct order for a framework that can read personal data.

## Boundaries: schemas, permissions, confirmations and workspace paths

The explicit execution boundaries are the part of the design worth studying, because they are the difference between a demo and something you would let on your own phone. The README lists four layers of control. Schemas validate what an action asks for. Android permissions are respected, so the framework does not pretend it can do what the operating system has not allowed. User confirmations gate the actions that matter. And workspace paths keep the agent inside the directories it is supposed to be in. All four are checked before a device action runs, which is a design that puts the guard rails in the runtime rather than in the prompt. The release history shows this area being tightened, with v0.1.5 in April 2026 described as unifying permission handling and fixing session, file and MCP permission issues, and v0.3.1 in August 2026 strengthening the workspace files. The roadmap also records per session turn coordination, so that a long running task in one session does not block every other session, which is a correctness point as much as a performance one.

## Channels, cron and an always-on mode that is really a service

The fifth feature is channels and automation, and the roadmap entries explain how the hard parts were handled. Tasks can be received from local chat or from connected channels, and scheduled work runs through Cron, a heartbeat, and an Always-on mode. The roadmap says the Always-on mode is kept as a foreground service shell, and that a process wide single runtime owner was added, which is the Android shaped answer to a problem that is easy to get wrong. An agent that is meant to run in the background on a phone is fighting the operating system's process lifetime, and the two techniques named, a foreground service and one owner of the runtime, are how you keep a long running agent alive without leaking a second runtime per session. The channels feature was also iterated on, with v0.1.4 in March 2026 about channel stability and v0.2.1 in June 2026 about unified gateway runtime, per session processing and chat scrolling, plus ClawHub browsing and review flows for skills.

## Sessions that remember, and a provider layer you choose

The fourth feature is persistence. Conversation history, tool traces, attachments, session workspaces and reusable memory are kept across turns, which is the difference between a chat window with a model attached and an agent that can be resumed. The tool traces matter most for anyone reviewing what happened, since a phone agent that reads your files and acts on them should be able to show its work. The sixth feature is extensibility, with built-in or custom LLM providers, MCP servers, and bundled or installed skills. The provider story was refined quickly, with v0.1.2 adding more provider presets, v0.1.3 adding custom provider names and improved endpoint auto detection, and v0.3.1 improving provider endpoint compatibility and chat response timing. The v0.1.1 release fixed the MiniMax endpoint and improved the Chinese error messages, which is a small detail that tells you the project has users whose providers are not the obvious ones.

## A paper, a release every few weeks, and 769 tests

The project is a research demonstration as much as a product, and the dates line up. The initial release v0.1.0 was on 2026-03-16, and by 2026-04-06 the project was on v0.1.5 with a UI refactor and unified permission handling. The paper was released on arXiv on 2026-07-16, and accepted to the EMNLP 2026 system demonstrations track on 2026-08-23, with v0.3.1 published three days later on 2026-08-26. The test count is the other number worth quoting, because the release notes tie it to the work, from 306 tests at v0.2.1 to 769 unit and instrumentation tests at v0.3.1, spread across the runtime, the UI state, the tools, the channels, the storage, the providers and the skills. The badge in the README carries the same figure. That is an unusual level of instrumentation for a project that started five months earlier, and it explains why the roadmap can talk about internal structure, a composition root and focused UI slices, since a test suite that size is what makes that kind of refactoring safe.

## Licensing, notices and what to check before you ship

The tree is explicit about the legal side, which is more than most repositories bother with. There is a `LICENSE` file and a `LICENSE-COMMERCIAL.md` next to it, so the project is offered under AGPL-3.0 with a separate commercial route, and a reader should treat the two as a package rather than pick one. There is also `THIRD_PARTY_NOTICES.md` and `THIRD_PARTY_UI_ASSETS.md`, which is the usual sign that a project bundles third party code and third party visual assets, and a `SECURITY.md` for reporting issues, and a `CONTRIBUTING.md` and a `CLA.md` that is the contributor licence agreement. The README is also published in Simplified Chinese, with the English file linked from the Chinese one, and the release notes record a Chinese docs release in March 2026. On the state of the project, the last push was on 2026-08-26, the same day as v0.3.1, so the tree is at the current release rather than ahead of it, and for anyone planning to depend on it, the released tag is the thing to pin.

## Conclusion

PalmClaw suits a developer who wants an agent that can act on the phone itself, with the session state, the memory and the tool history living locally rather than on a server, and it suits anyone interested in how a mobile agent enforces boundaries, since the schema and permission checks are described in unusual detail. It is a poor fit if you need the model to run locally as well, because the inference is explicitly delegated to a user configured LLM API, and it is a poor fit for commercial use without reading the terms, since the repository carries an AGPL-3.0 licence next to a separate commercial licence file. Before you build on it, check three things: which LLM provider you will point it at and what that costs per turn, how the permission and workspace boundaries behave on the Android version you target, and the licensing, since the AGPL and the commercial file sit side by side in the tree and the third party notices are there for a reason.

## FAQ

### What is PalmClaw?

An open source agent framework for Android, written in Kotlin, that runs directly on a phone without a separate PC. It keeps sessions, context management, memory, skills, tools and the agent loop on the device, while model inference comes from an LLM API you configure.

### How does PalmClaw keep its actions under control?

With four layers checked before a device action runs, schema validation, Android permissions, user confirmations, and workspace paths. The release history shows the permission handling being unified in v0.1.5 and the workspace files expanded in v0.3.1.

### What can PalmClaw do with the phone?

Files, personal data, hardware, web, communication and automation are reached through typed device operations with structured results rather than a general command interface, and the tool set is browsable from a tool management page in the app.

### Can PalmClaw run scheduled tasks in the background?

Yes, through Cron, a heartbeat and an Always-on mode. The roadmap records that Always-on is kept as a foreground service shell and that a process wide single runtime owner was added, which is how a long running agent stays alive on Android without one runtime per session.

### What licence is PalmClaw released under?

The repository is AGPL-3.0 and ships a separate LICENSE-COMMERCIAL.md next to the licence file, along with third party notices for code and UI assets. The project also publishes a paper accepted to the EMNLP 2026 system demonstrations track, and v0.3.1 raised coverage to 769 tests.

## Sources

- [License: AGPL-3.0](https://github.com/ModalityDance/PalmClaw/blob/main/LICENSE)
- [ModalityDance/PalmClaw on GitHub](https://github.com/ModalityDance/PalmClaw)
- [Project website](https://modalitydance.github.io/PalmClaw/)
- [README](https://github.com/ModalityDance/PalmClaw/blob/main/README.md)
- [Releases](https://github.com/ModalityDance/PalmClaw/releases)

---

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