# openclaw-assistant, a repository named for the app it replaced and a readme carrying both

> The Android voice client at the centre of this repository now presents itself as a successor app with two interchangeable agent backends, while the readme is two documents stapled together and every internal link still points at the previous repository path. Underneath that sit a migration that always keeps the old backend primary, a watch configured by hand, and screen control plus SMS gated behind a build flag.

**yuga-hashimoto/openclaw-assistant** — OpenClaw voice assistant app for Android - Wake word activation & system assistant integration

- Repository: https://github.com/yuga-hashimoto/openclaw-assistant
- Stars: 321 · Forks: 90
- Language: Kotlin
- License: MIT
- Published: 2026-09-15 · Updated: 2026-09-15 · Language: en
- Canonical page: https://hysenlabs.com/projects/yuga-hashimoto-openclaw-assistant

## The repository is named for the app it replaced

The project's own headline is a different name. The readme opens with WakeHermesClaw for Android, calls that app the successor to OpenClaw Assistant, and then continues below a horizontal rule into the previous readme under its own title. The repository slug is a third spelling of the same thing: neither of the two names in the file, and a mix of lower case and capitals with no hyphen.

Every internal link resolves to the older spelling. The release download link, the licence link, and the documentation links in the legacy half all address a path under the same account with a capitalised, unhyphenated name. So the page a reader is on and the pages it points at are two different strings, and the link labelled as the download points somewhere the readme never mentions.

The repository's one line description is a third version again. It names an OpenClaw voice assistant for Android with wake word activation and system assistant integration, with no mention of the second backend that now takes half of the readme. That description is the text search engines index, so the project is still listed as a single backend client.

## The quick start link lands in the previous product's instructions

The first half of the readme is written entirely as a block quote, which is how a notice gets attention without displacing anything. Underneath it, the legacy document resumes with its own badges, a language switch offering Japanese and English, a demo video, and a six cell screenshot table whose cells are captions with no images in them.

The navigation at the top of that legacy half offers a link to a five minute quick start. Following it lands on five numbered steps for the old product: install the latest APK, run a pairing command on your server, tap a button labelled Scan QR Code, approve the device on the server, and then hold the home button or say the wake word.

The successor section documents a different setup with a different command and a different screen. You start a gateway with an API server enabled on a default port, bind it to your network, generate a key, and add the server through a settings screen. Nothing in either half says which of the two instruction sets applies to a build you download today, and nothing says whether the anchor at the top of the file has been updated to point past the legacy half.

## The migration always makes the old settings the primary backend

Upgrading is meant to be invisible, and the mechanism is described in detail. The application identifier is unchanged, so the install replaces the old app rather than sitting beside it. On first launch the app copies the previous gateway and HTTP settings into a new structure that can hold several backends, and then marks the copied configuration as the primary one.

That last step decides where your traffic goes. Wake word activation, a background hotword service, the voice overlay, the watch integration, and the on device node capabilities are all stated to keep targeting the primary backend. So an existing user who adds the second agent server alongside the first has not changed anything about how the phone behaves; the new server is configured and unused until the role is changed by hand.

The watch is a separate case again. It carries its own backend address and its own authentication token, and the readme states plainly that the phone's primary backend is not pushed to it. A user who configures the phone carefully and then raises their wrist gets an unconfigured watch, and the fix is to enter the address and the key on the watch as well.

## The connection test asks an OpenAI path first and a Hermes path second

Adding a backend is a short sequence, and it is written out as a thirty second task. Start the gateway with the API server enabled, which listens on port 8642 by default. Bind it to your local network or your VPN. Generate a key. Then enter the host and port through the backends section of settings.

The address can be given with or without a version path segment, and both forms are accepted. That means the app has to normalise what you type before it builds a request, and the readme does not say which of the two forms ends up in the request it sends. Authentication is a bearer header carrying the key, and the model name defaults to a value identifying the agent. Plain HTTP is what the examples use, on a local address.

Then there is the connection test, and its two steps are the interesting part. It calls a model listing endpoint first and, if that does not answer, falls back to a health endpoint. The first is the path an OpenAI compatible server exposes; the second belongs to the agent's own server. A backend that answers only the second will pass, and so will one that answers the first for a different reason, which means a green test does not tell you which of the two contracts your server actually implements.

## Accessibility control and SMS are compiled out of the store build

The app can tap, swipe, press home and back, and describe the window in front of it. That set of actions is the difference between a voice assistant and a remote control for your phone, and in this project it is marked as available only in sideloaded builds.

The mechanism is a build flag with a name that reads as a boolean. When it is off, the accessibility bridge and SMS are left out, and the flag is described as gating them for a build on the Play track. Every other capability in the feature list, including the voice overlay, the watch app, and the full set of text to speech providers, is outside that gate.

What is missing is any statement about which value the released artifact carries. The install path documented for users is an APK from the releases page, and the readme never says whether those APKs are built with the flag on or off, nor does it name a Play track build that a user could compare against. The two capability sets are not a preference difference; one of them cannot be enabled after installation.

## The bridge races three endpoints at once, one of them on the public internet

An optional component lets the agent reach a curated set of phone capabilities over a local HTTP service protected by a bearer token. It is off by default, and it has its own documentation file and its own integration directory, both named for the second backend rather than for the app.

The access model is more careful than the feature list suggests. Pairing uses a six character code. Setup can arrive as a deep link payload instead of typing. Grants are per capability and expire on a timer, with three durations offered: ten minutes, an hour, or until revoked. There are endpoints to list and to revoke grants. And there is an override for destructive verbs, which implies a standing list of verbs treated as destructive, a list the readme never prints.

The connection behaviour is the part to know about. On connect, the app races several endpoint candidates in parallel rather than trying them in order, and the candidates are named as local network, VPN, and public. A parallel race against a public address means the phone opens a connection outward while trying the local ones, on every connect attempt, whether or not the local candidate would have won.

## A canvas tab appears in the screenshots and in neither feature list

The screenshot table has six labelled cells: home, a voice overlay, a conversation list, a canvas, settings, and chat. The canvas cell is labelled with an acronym for a UI format driven by the agent rather than by you, and the legacy feature list has a matching bullet describing a canvas tab for richer agent driven interface.

The successor half does not mention it. The migration paragraph enumerates what continues to work, and the canvas is not in that list: the wake word, the hotword service, the voice overlay, the watch, and the node capabilities are all named, and the canvas is the one user visible surface from the old screenshots that is not. The new feature inventory covers backends, pairing, grants, the bridge, the watch, and builds, and stops there.

Two other details in the same passage are worth pulling out. A component called the hotword service is named in the migration inventory and never explained anywhere in the visible text, so a reader cannot tell it apart from the always-on wake word detector that runs a local recognition model on the device. And of the four text to speech providers listed, the last one is marked as available in the full build, which is the second reference to a build variant whose difference is never defined.

## Three working notes sit in the root beside five process documents

The repository root holds twenty one entries. Five of them are process documents: an agent instructions file, a building guide, a code of conduct, a contributing guide, and a third party licence list. Four more are build files and a wrapper script. Two are modules for the watch and for shared code, one is the app module, and one is the directory holding the bridge integration.

The rest are not part of a build. There is a plan document, a file holding a pull request body, a file listing test topics, and a dot directory named after an assistant tool. Those three text files read as working material that was committed to the root rather than filed under the documentation directory, which already exists and is the natural home for them.

The build line is short enough to state in full:

```bash
./gradlew testDebugUnitTest assembleDebug
```

One test task and one debug assembly, no release task, no signing configuration, and no versioning task. That matches the release history, where the newest published version is a four field patch number from late April 2026, while the default branch was last pushed on 29 August 2026, four months later. The build anyone gets from the store is therefore older than the source in the repository, and no changelog bridges the two.

## Conclusion

Install this if you run your own agent gateway and want voice, wake word, and device control from an Android phone without a cloud assistant in the middle. Check four things first. Which build you are getting, because accessibility control and SMS are compiled out of the store track and the readme does not say which track the release APK belongs to. Which backend is marked primary after the upgrade, because the migration always assigns that role to the settings it carried over. Whether you are willing to paste a bearer token and a LAN address into a phone app over plain HTTP. And whether you will keep the watch configured by hand, since the phone's primary backend is not pushed to it.

## FAQ

### what is openclaw assistant and what does it do?

It is a native Android voice client built for a self-hosted agent gateway, with offline wake word detection, continuous conversation, a voice overlay, system assistant integration through long press home, and a Wear OS app. Sensitive values such as server addresses and tokens are stored with AES256-GCM encryption, and the wake word engine runs locally with Vosk.

### What is OpenClaw and what does it do?

OpenClaw is the server side the app connects to. The client speaks to it over a WebSocket gateway with pairing, QR enrolment and TLS, or over an HTTP chat endpoint that is OpenAI compatible. A second backend type is an agent API server offering a streaming chat completions path and a runs path.

### Can OpenClaw be used as a personal assistant?

The app is built for that shape of use: hold the home button or say a wake word, talk in continuous conversation, and have the agent act on the device through notifications, camera, contacts, calendar, apps, clipboard and WiFi. Those capabilities are opt-in and guarded by Android permissions or explicit user actions, and the tap, swipe and window describe bridge is limited to sideloaded builds.

### Is OpenClaw AI free?

The readme does not address pricing. What it does state is that the project requires no API key of its own, that a second backend requires you to run your own server on port 8642 and generate your own key, and that the text to speech providers include two hosted services alongside the on-device engine.

## Sources

- [Issues](https://github.com/yuga-hashimoto/openclaw-assistant/issues)
- [License: MIT](https://github.com/yuga-hashimoto/openclaw-assistant/blob/main/LICENSE)
- [README](https://github.com/yuga-hashimoto/openclaw-assistant/blob/main/README.md)
- [Releases](https://github.com/yuga-hashimoto/openclaw-assistant/releases)
- [yuga-hashimoto/openclaw-assistant on GitHub](https://github.com/yuga-hashimoto/openclaw-assistant)

---

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