Minke: a desktop workspace for DeepSeek Harness

What Minke adds on top of DeepSeek Harness

DeepSeek Harness is the agent runtime. Minke is the window around it. The README describes it as "a native desktop workspace for DeepSeek Harness", and the package description calls it a "desktop agent powered by DeepSeek Harness". That framing matters more than it first appears. A harness on its own gives you a runtime and a command surface; you supply the editor, the file browser, the terminal, the browser and the way you reach it from a phone. Minke bundles those into one Electron application.

The target reader is someone already running agentic coding or research tasks locally and tired of alt-tabbing. The right and bottom panels hold Files, Terminal, Browser, Browser History and Plugins next to the conversation, and the README says the app ships native menus and customizable shortcuts. Two claims in the highlights are worth separating. "Local-first by design" covers sessions, settings, Browser History and browser session data, which the README says stay on your machine. "Local model support" covers discovery of LM Studio, Ollama and other loopback OpenAI-compatible services. Those are different promises: one is about where data lives, the other about which model answers.

The project is explicitly not official. A callout states that Minke is "an independent community project, not an official DeepSeek product", and the repository is licensed Apache-2.0. If your procurement process requires a vendor relationship, that sentence ends the conversation.

How the desktop app, the host and the plugins fit together

The repository layout tells you most of the architecture. There is a desktop/ directory for the Electron app, a packages/ directory for workspace packages, and separate Vite configs for the main process, the preload script, the renderer, and a fourth one named vite.tabs-web-preload.config.mts. That last file is the interesting one: it implies tab content is loaded as web content with its own preload bridge rather than as ordinary renderer components.

The packages are named in the typecheck script, which is the clearest inventory the repository gives. There is @lencx/minke-remote-access, @lencx/minke-model-runtime, @lencx/minke-harness-overlay, and three chat integrations: @lencx/minke-im-weixin, @lencx/minke-im-telegram and @lencx/minke-im-discord, plus a gateway package that presumably fronts them. So remote access is not a feature bolted into the main process; it is a package, and the messaging channels are separate packages behind a common gateway.

Remote access itself is described precisely in the README, and the precision is useful. It is "a responsive Web client backed by Minke Host", not a video stream or a touch-controlled projection of the Electron window. That distinction decides what you can do from a phone: continue conversations, start agent tasks, manage project files, and use a terminal that runs on the Minke computer. The README also states that Minke activates only one remote route at a time, owns its foreground proxy while running, and stops it on exit. Three routes are listed as having completed end-to-end regression testing: Tailscale Serve over HTTPS, Tailscale Direct IP, and Cloudflare Access. The README recommends HTTPS Serve and says it keeps Harness on the local loopback address, does not bind it to the LAN, and does not enable public Tailscale Funnel. Direct IP binds only to the device's Tailscale IPv4 and is HTTP, so it is not a browser secure context. Cloudflare Access needs a configured tunnel, an Access application and an explicit allow policy.

Installing Minke and taking control of a live browser tab

Minke ships as a desktop package, not as a package-manager install. The README is blunt about the source: download it only from the official GitHub Releases page, and the table there links to the latest stable artefacts per platform and architecture. There is no npm or Homebrew instruction in the README, so treat any other download page as unverified. The release checksums are published alongside the downloads, which is the one integrity check you can perform before running the binary.

The per-platform artefacts are:

# macOS, Apple Silicon
Minke-macos-arm64.dmg
# macOS, Intel
Minke-macos-x64.dmg
# Windows x64
Minke-windows-x64.exe
# Debian / Ubuntu x64
Minke-linux-x64.deb
# Fedora / RHEL x64
Minke-linux-x64.rpm
# Linux x64, portable
Minke-linux-x64.AppImage

After launch, the first task worth trying is the agent browser, because it is the feature that most changes how you work. The README says agents can search, open and interact with the Web in visible browser tabs, that you can take control of a live tab without closing it, hand it back when ready, or send annotated page context to the conversation. The visible-tab part is the design decision: the agent does not act in a hidden headless browser you cannot inspect.

Remote access is the second thing to try, and it has a fixed order. Install Tailscale on the Minke computer and the phone, sign both into the same tailnet, and confirm the computer is connected. Then, in Minke, open Connections, then Device access, then Remote access, select HTTPS Serve, and enable remote access. The README says Minke connects in the background and no restart is required. Copy or open the displayed address on the phone.

Connections → Device access → Remote access → HTTPS Serve → enable

If you want it as an app rather than a tab, open a Tailscale Serve or Cloudflare Access HTTPS address, choose Install Minke in the sidebar, and accept the browser prompt. On iPhone or iPad the README points to Share, then Add to Home Screen. The installed app launches in standalone mode and, when connectivity is poor, shows connection or offline feedback instead of silently presenting cached workspace content. That last behaviour is a deliberate choice against stale-data confusion.

Where Minke is the wrong tool

The README carries its own warning, and it is not boilerplate: "Minke is under active development. Features, packaging, and the local data schema may change as the project evolves." A changing local data schema is the expensive kind of change. Sessions, settings and Browser History live on your machine by design, which is good for privacy and awkward for migrations. If you build a workflow that depends on reading Minke's stored session data directly, you are building on a format the project has told you it may revise.

Remote access has a sharper constraint. Only one remote route is active at a time, and the foreground proxy is owned by the running app and stopped on exit. That means the remote workspace is unavailable whenever Minke is not running, and switching between Tailscale and Cloudflare is not a concurrent arrangement. The README also notes that the remote page can start agent tasks and use local tools already authorized in Minke, and tells you to grant access only to trusted tailnet members or Cloudflare Access identities. This is a real capability with a real blast radius: a phone on your tailnet can drive tools on your desktop.

Tailscale Direct IP is the weakest of the three routes for a mundane reason. The README says the address uses HTTP and is not a browser secure context. That rules out PWA installation and any browser feature gated on secure contexts, so it is an advanced fallback rather than a default. Cloudflare Access, meanwhile, requires you to already have a tunnel, an Access application and an allow policy; Minke does not create that infrastructure for you.

Finally, if you want a harness you can embed in your own CI or script against a stable API, a desktop application is the wrong shape. Minke is a workspace for a person at a machine.

Minke compared with running the harness in a terminal

The honest alternative is not another desktop agent. It is the harness itself, driven from a terminal, plus whatever editor and browser you already use. That setup has no Electron process, no local session store to migrate, and no proxy lifecycle to reason about. It also has no shared-control browser tab, no side-by-side Files and Terminal panels bound to the conversation, and no PWA you can open on a phone.

The difference is not features versus no features. It is where the state lives and who owns the loop. In a terminal workflow you compose the pieces and you own the integration; when the harness changes, you change your scripts. In Minke the integration is the product, and the project owns it, which is why the README can promise things a terminal cannot, such as taking control of a live agent tab without closing it or sending annotated page context into the conversation. The cost is that you inherit Minke's release cadence. The release history bears this out: v0.3.0 on 2026-08-25, v0.4.0 on 2026-09-03, v0.5.0 on 2026-09-05, with the repository's package.json already at version 0.6.1. That is a project shipping quickly, which cuts both ways for anyone pinning a workflow to it.

A second alternative is narrower: use Minke only as a remote-control layer. The messaging integrations for WeChat, Telegram and Discord, and the responsive web client, are useful even if you keep your main work in a terminal. The README does not describe a headless mode, so this would mean leaving the desktop app running.

Maintenance, licensing and what to verify before you commit

Maintenance signals are mixed but readable. The last push to the default branch was on 2026-09-05, and v0.5.0 was released the same day, so this is not a dormant repository. The README's own development warning is the counterweight: fast releases on a young project usually mean churn in exactly the places you would prefer stability, which here is packaging and the local data schema.

The repository is licensed Apache-2.0, and package.json declares the same identifier. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices; it does not oblige the maintainer to keep publishing releases or to accept contributions. Note also that package.json sets "private": true, which affects npm publishing, not the licence terms of the source. Nothing in the README describes a commercial edition, a hosted service or a paid tier, so there is no separate commercial licence to reason about. This is a description of what the files say, not legal advice; if your organisation has licence review, run the Apache-2.0 text past it.

Upgrade cost is the part to test before you depend on Minke. The app has built-in updates according to the README, and the release cadence is roughly weekly at the time of writing. What the README does not document is rollback, and it does not describe a migration path for the local session, settings or Browser History stores. So the thing to verify first is not a feature. It is whether your sessions survive an upgrade, and whether you can return to a previous release if they do not.

Editorial conclusion

Adopt Minke if you already run DeepSeek Harness and want its sessions, files and terminal in one window on macOS, Windows or Linux, and you accept that the README flags changing features and a changing local data schema. Do not adopt it if you need a stable plugin API or a long-lived on-disk format, and do not treat it as an official DeepSeek product. Before installing, confirm the release checksum published alongside the package you download, and read the remote access note: Minke runs one remote route at a time and stops its foreground proxy on exit.

Frequently asked questions

Official sources

1. Issues
2. lencx/Minke on GitHub
3. License: Apache-2.0
4. README
5. Releases