Dsh Mobile: DeepSeek Harness sessions and agent runs on your phone

What it is: Harness without a browser

DeepSeek Harness runs where you started it, on a computer, and Dsh Mobile is the community's answer to checking on it from a phone. The client connects through the dsh-plugin-mobile-gateway plugin over a WebSocket and carries workspaces, sessions, realtime replies, agent trajectories and files to iOS and Android. The README describes the visual language as continuing the DeepSeek WebUI's restrained style, and the screenshots show a deep-sea palette with whale imagery carried through light and dark themes.

The architecture badge is Kotlin Multiplatform, and the project is explicit that the two apps are not a shared UI. Each platform gets native interfaces, Jetpack Compose on Android and SwiftUI with UIKit on iOS, while business rules converge in a shared core. The whole project is MIT licensed.

The shared core and the two native shells

The shared module, commonMain, is the single source of business state: Gateway protocol DTOs and a wire decoder, Store and Reducer layers for sessions, questions, approvals and session control, incremental projections for conversations and trajectories, history synchronisation with dedupe, and workspace file state machines. The README is precise about the boundary: the shared layer never touches Compose, SwiftUI, the Android framework or Apple UI frameworks, and it does not operate the platform file system directly.

Platform shells own everything system-shaped. Android pairs Compose with OkHttp's WebSocket, DataStore for non-sensitive configuration and Keystore for credentials, plus CameraX and ML Kit for QR scanning and a foreground service for connection upkeep. iOS uses URLSession's WebSocket, UserDefaults and the Keychain, with QR pairing and the system's background execution time. The README draws the whole flow as one diagram, and most of its lines show how one shared core feeds two native shells:

                         DeepSeek Harness
                  dsh-plugin-mobile-gateway
                             WebSocket
                ┌───────────────┴───────────────┐
                │                               │
     Android OkHttp Transport          iOS URLSession GatewayClient
                │                               │
       KMP Gateway Runtime             Swift Router / KMP Adapter
                │                               │
                └───────────────┬───────────────┘
                    KMP shared / commonMain
            Protocol · Store · Reducer · Projection
       History Sync · Question/Approval · Workspace Files
                ┌───────────────┴───────────────┐
                │                               │

One honest asymmetry is documented: iOS reuses the shared Store, Reducer, projections and file state machine, but its Swift GatewayClient still handles WebSocket and reconnection, and has not yet adopted the full KMP Gateway Runtime that Android runs.

Pairing a phone to your Harness

The server side needs one plugin. Every release since 1.5.1 raises a minimum gateway plugin version and asks for a full restart of dsh web after installation, and the release notes document a single dsh plugin add command for the web profile that installs the mobile gateway; for the current v1.5.3 that means dsh-plugin-mobile-gateway v0.7.5 or newer. On the phone, pairing works by scanning the WebUI's QR code or typing the pairing details manually, and long-term credentials go into the platform's secure storage, Keystore on Android and Keychain on iOS.

Since v1.5.1 the app manages multiple gateways: you can save several computers or servers, switch the active host from the home screen, edit host names and types, and delete profiles singly or in bulk. Switching hosts isolates sessions, workspaces, files and connection state, so one machine's context does not bleed into another's.

What the chat can do mid-agent-run

The realtime surface handles WebSocket incremental events and renders Markdown, code, the model's thinking process, tool calls, tool results and image attachments. Version 1.5.3 added queued messaging while an agent reply is still streaming: you can type ahead, then edit, delete or promote a queued message to an interjection.

History is deliberately decoupled from the live tail. Paging backwards loads old records while the live end of the conversation stays put, and deduplication runs by sequence number and event identity so reloads do not duplicate messages or roll the transcript back. The trajectory view shows User, Assistant and Tool events with call parameters, results, schemas, token counts and durations. Interactive agent flows are first-class: Human Question prompts and tool approval requests can be submitted, cancelled, rejected or allowed once from the phone.

Session defaults are managed remotely too: agent presets, provider and model selection, thinking level, and the Harness agent permission modes named read-only, workspace-write and danger-full-access. The README is careful to note these are Harness permissions, not phone-local file system permissions.

Files, workspaces and the background ceiling

Workspace support covers browsing, creating and switching workspaces on the Harness host, and searching, creating, switching and archiving sessions. Workspace files go further: you can browse remote directories, download files in chunks with integrity verification, preview common code formats, or hand a file to the system's own apps. The facade layer tracks chunk order, progress and SHA-256 verification, so a dropped connection mid-download does not produce a silently corrupt file.

The lifecycle story differs by platform, and the README states the ceiling plainly. Android keeps the connection alive during agent turns with a foreground service. iOS uses the limited background execution time the system grants, and does not guarantee an indefinite WebSocket connection, so a long agent run may simply pause its live updates when iOS suspends the app. Anyone planning to supervise hour-long runs from an iPhone should plan around that.

Recent releases move in lockstep with the plugin

Three releases landed in five days: v1.5.1 on 2026-09-12 brought multi-gateway management, v1.5.2 on 2026-09-13 adapted to the DSH 0.1.5-rc.2 assistant realtime stream and fixed an iOS stack overflow when rendering very long assistant messages, and v1.5.3 on 2026-09-16 added queued messages plus fixes for session snapshots, history loading, reconnection and a Unicode decoding failure in older sessions.

The pattern to notice is the dependency coupling. Each release raises the required mobile-gateway plugin minimum, 0.7.3, then 0.7.4, then 0.7.5, and each insists on a full restart of dsh web. Updating the app without updating the plugin on the host is the documented path to mismatch, so treat the phone client and the server plugin as one versioned unit. The last push was on 2026-09-16, the same day v1.5.3 shipped.

Editorial conclusion

Dsh Mobile fits DeepSeek Harness users who want to watch sessions, read trajectories and answer approval requests from an iPhone or an Android phone rather than a browser tab. It does not fit anyone without a running Harness deployment, since it is a client and needs the mobile-gateway plugin v0.7.5 or newer on the host, and it does not fit iOS workflows that require guaranteed background streaming. Before relying on it, install the matching gateway version and restart dsh web, pair through the WebUI QR code, and test how long your typical agent runs stay visible on iOS. The last push was on 2026-09-16, and the plugin-version coupling is documented in every release note.

Frequently asked questions

Official sources

1. Clarklevis1995/dsh-mobile on GitHub
2. Issues
3. License: MIT
4. README
5. Releases