DeepSeek Harness on mobile: LAN, QR and public entry

DeepSeek Harness has no official mobile app; mobile means a browser reaching the Web UI. The difference lies in how the phone reaches the service: same-LAN direct, sending the link, or a public entry.

Start with the fact: no official app

People searching for an Android or iPhone build should accept one fact: there is no official app. Mobile uses the browser interface (source).

No app does not mean a poor experience. Sessions, plugin market, and files are all in the Web UI; adding it to the home screen feels close to a lightweight app.

Do not install unofficial mobile clients. They may request an account or token with more risk than benefit; if the vendor has not released one, do not look for substitutes.

Path one: same LAN

The fastest path: phone and computer on one Wi-Fi, phone browser opens the computer's LAN address.

1. Confirm the service listens on a LAN address or allows LAN access, not only 127.0.0.1.
2. Find the computer's LAN IP, such as 192.168.x.x.
3. Open http://computer-ip:port in the phone browser.
4. If authentication is required, log in on the computer or copy the tokenized link.
5. Add the page to the home screen for next time.

Listening only on localhost is the most common failure. The service opens on the computer but not on the phone; confirm the network is trusted before widening the listen address.

The router may isolate clients. With client isolation, same-Wi-Fi devices cannot see each other; test with a hotspot to confirm instead of changing the service repeatedly.

Path two: send the link to your phone

QR codes, chat messages, and copied links are all "transport the address." This is not a separate access method.

1. Open a working Web UI address on the computer.
2. Send it to the phone with a QR tool or a chat app.
3. Open the link and confirm the domain, port, and computer match.
4. If the link contains a token, do not forward it to groups or public channels.
5. Check whether a new login is required.

QR is not an official feature. It only transports the address; reachability depends on listen scope and network.

A tokenized link is a temporary key. Keep the audience small and regenerate after use to avoid long-lived exposure.

Path three: public entry

When not on the same network, use a reverse proxy or tunnel. The focus is not "can it open" but "who can open it."

1. Configure a reverse proxy on the server or gateway, pointing to the local web service.
2. Configure a TLS certificate so mobile access uses HTTPS.
3. Add authentication and source limits; do not rely on an obscure port.
4. Test on cellular data to confirm it does not depend on the LAN.
5. Keep access logs and review unusual sources.

Never expose the service port directly. Without authentication and TLS, the workspace is open to everyone.

Tunnels suit temporary access. They avoid domain and certificate setup but depend on a provider; long-term use should move to a reverse proxy with authentication.

Three paths compared

Choose by same network, duration, and number of users.

Prefer LAN, use public only when remote. Public access has the highest security cost; avoid exposing when the LAN works.

The three can coexist. LAN at home, public when traveling; keep authentication consistent so one path is not weaker.

Authentication and security

Mobile expands the exposure surface; authentication must be stricter.

1. Enable authentication: at least a login or token, never "nobody knows the address."
2. Limit sources: restrict public entry by IP or subnet to reduce scanning.
3. Use HTTPS: public access must be encrypted so tokens do not leak.
4. Rotate tokens: regenerate after sharing or device loss.
5. Close unused entries: disable the proxy when public access is unnecessary.

Security is ongoing, not a one-time setup. An open entry needs log review; an unmanaged public entry is the easiest target.

Treat a lost phone as a credential leak. Revoke tokens, change passwords, and check logs together.

When the phone cannot connect

Check network, listen address, firewall, and authentication in order.

1. Network: same Wi-Fi? Router client isolation enabled?
2. Listen: is the service on 127.0.0.1 only? LAN access needs the right address.
3. Firewall: is the port blocked? Test temporarily, then add a rule rather than disabling it long term.
4. Authentication: login page, expired token, or error message?

Do not reverse the order. Starting with authentication misreads "network unreachable" as "wrong password."

Keep one piece of evidence per layer. Ping reachability, port connectivity, login page presence; then change configuration.

Next steps

Confirm LAN access before going public. For base mobile configuration, read How to use DeepSeek Harness on mobile. For remote SSH, read How to configure remote access. For reverse proxy details, read DeepSeek Harness reverse proxy.

Sources: DeepSeek Harness docs, dsh CLI README, deepseek-harness repository