Choose the operating model first
Mobile projects can look interchangeable in a directory even though they place execution, credentials, files, and network exposure in different locations. The registry keeps these models separate.
| Model | Where DSH runs | What the phone does |
|---|---|---|
| Remote companion | Desktop, workstation, or server | Controls an existing Web or Headless session through a gateway, browser, or messaging channel |
| Native Android client | A separate Harness host | Provides a native conversation and control surface connected to that host |
| On-device DSH | The Android device itself | Runs the Harness and plugin graph locally, commonly through a terminal environment |
Remote companion
This is usually the smallest operational change because the established host keeps its files, profiles, plugins, and compute. Review how the project authenticates each device, limits network exposure, transports approvals and files, and revokes a lost phone.
- Prefer an explicit pairing or device-token flow over an unauthenticated LAN endpoint.
- Record whether traffic stays on a private network, uses a tunnel, or crosses a public relay.
- Treat remote shell, file transfer, approvals, and credential settings as separate capabilities.
- Test reconnect and token revocation before relying on the companion away from the host.
Native Android client
A native client can provide platform navigation, notifications, and touch-first interaction without pretending the full Harness runs on Android. An August 25 Show Your Plugins post demonstrates this category with a Kuikly-based Android client. That post is a community project announcement in the official repository, not an official DeepSeek mobile release.
On-device DSH
Running DSH locally moves the Node runtime, profile, plugin storage, model credentials, and tool permissions onto the phone. Evidence from a desktop or server does not carry over: the exact Android environment, architecture, terminal runtime, DSH version, plugin artifact, and surface all need their own observation.
What Android evidence should record
A useful mobile record starts with the same exact compatibility cell as any other platform, then adds the operating model and connection boundary.
- Exact plugin or client artifact, DSH host version, Node version, profile, device architecture, and observation time.
- Remote companion, native client, or on-device classification.
- Install, registration, boot, reconnect, and one capability-specific observation as separate fields.
- Network path, authentication method, credential location, file-access boundary, and evidence expiry.
DeepSeek Harness is in developer preview. Recheck official documentation and plugin evidence when the host version changes.
Sources and evidence
Official documentation and community evidence are labeled separately in the source pages and in this article.