DeepSeek Harness desktopapp: wat de installer echt op je machine zet

De DeepSeek Harness-desktopapp is een Electron-shell rond dezelfde webinterface die je krijgt via npx @deepseek-ai/dsh web, en wordt geleverd als drie platformspecifieke installatieprogramma's voor een harness die momenteel op versie 0.2.1-rc.2 staat. Die beschrijving klinkt geringschattend, maar zo is ze niet bedoeld. Een werkende interface in een desktopcontainer verpakken is werk van een weekend; het in een container verpakken die een eigen runtime-map bezit, je taken in leven houdt wanneer je het venster sluit, zichzelf bijwerkt op een kanaal zonder stabiele release en je sessies bij al die bewerkingen behoudt, is het deel dat maanden kost, en dat is het deel dat het lezen waard is. Als je DeepSeek-V4.1-Flash wilt draaien via een harness die in een venster huist in plaats van in een terminal, dan is dit die build, en de interessante vragen gaan allemaal over wat er rond het venster gebeurt.

Twee dingen moeten gezegd worden voordat de details volgen. Ten eerste vervangt dit artikel ons eerdere advies dat er geen desktopapp was — dat advies klopte toen het in augustus 2026 werd geschreven, en het is nu onjuist. Ten tweede is dit een openbare preview, nog steeds als zodanig aangeduid op de eigen site van DeepSeek, en de verpakking heeft de ruwe randjes die dat label impliceert. De installer werkt. De distributie eromheen is dunner dan je zou vermoeden.

Wat de desktopbuild eigenlijk is

De desktopapplicatie is een dunne Electron-laag wiens taak het is een Host-proces te starten en een venster daarop te richten. Het venster bouwt niet zijn eigen chatinterface op: het laadt de verpakte Web-entry die in de app is gebundeld op dsh-app://app/, en de updatedialoogvensters die je zult zien, komen van een tweede gebundelde origin op dsh-app://shell/. Er wordt een onderliggend Node-proces gestart in de RunAsNode-modus van Electron om de gedeelde profielrunner te starten, en de shell stuurt HTTP door naar de geauthenticeerde Web Host, waarbij de transfer-encoding, connection en keep-alive-headers onderweg worden weggelaten. Reacties van pluginbundels worden gemarkeerd als no-store, een klein detail met een zichtbaar gevolg: wijzig een plugin en de volgende herlaadbeurt toont de wijziging.

Omdat de URL dsh-app:// is in plaats van localhost, hoef je geen vaste poort te onthouden en is er geen poortconflict omheen te werken. De desktop-Host luistert standaard op een poort die door het besturingssysteem wordt toegewezen. Als je een specifieke poort nodig hebt, kun je die instellen via een webserver.config.port-override, maar de standaardwaarde is bewust geen constante, en de Host bindt aan 127.0.0.1. Dit is belangrijk als je oudere instructies hebt gevolgd: het nummer 19387 dat in augustus de ronde deed in installatiehandleidingen is niet de desktoppoort, en als je het daarvoor aanziet, ga je op zoek naar een service die er niet is.

Het vastpinnen van versies is strenger dan het op het eerste gezicht lijkt. Electron en @deepseek-ai/dsh hebben altijd exact dezelfde versie — geen bereik, geen compatibel majorversienummer — dus een upgrade van de harness is een desktoprelease, en er is geen ondersteunde combinatie van een nieuwe dsh en een oud venster. Het Electron-proces neemt een single-instance-lock voor de duur van het proces en bezit exclusief $DSH_HOME/profiles/desktop. Die exclusiviteit is reëel: de CLI kan dat profiel niet opstarten, en een via npm geïnstalleerde dsh kan er niets aan wijzigen. Wat de twee installaties wél delen, is de status die voor jou van belang is — sessies, instellingen, inloggegevens, workspaces en opslag, allemaal onder $DSH_HOME. Wat ze niet delen, zijn uitvoerbare pakketten, pluginactivering, lockfiles of node_modules, en daarom is het installeren van een plugin in het desktopprofiel niet dezelfde handeling als het installeren ervan in het CLI-profiel.

Drie installatieprogramma's, één updatekanaal, geen stabiele release

Er bestaan drie installatieprogramma's en alle drie reageren. Het Windows 64-bit uitvoerbare bestand is 289,385,456 bytes en wordt geserveerd met HTTP 200. De Apple-silicon-schijfkopie is 264,990,950 bytes, ook 200. De Intel Mac-schijfkopie is 289,480,824 bytes, ook 200. Alle drie zijn voor het laatst gewijzigd op 17 oktober 2026. Slechts twee ervan zijn vanaf de downloadpagina gelinkt. De Intel-build is live, is bereikbaar, en er staat op deepseek.com/en/harness/ nergens een link die erheen wijst — als je op een Intel Mac zit en de pagina hebt gevolgd, zou je redelijkerwijs concluderen dat er geen build voor jou was.

De Intel-build loopt ook een versie achter. De updatefeed ervan vermeldt 0.2.1-rc.1; de feeds voor Windows en Apple-silicon vermelden beide 0.2.1-rc.2. Eén release candidate is geen groot verschil in functies, maar het is een echt signaal over welke doelen eerst worden gebouwd en welke het laatst worden geverifieerd, en het is precies het soort ding dat je wilt weten voordat je je werksessies aan een platform toevertrouwt.

De updatekanalen zijn waar het distributieverhaal dun wordt. De feeds zijn per target, onder /dsh-desk/feeds/<target>/ op dezelfde host. Windows x64 verwijst naar nightly.yml; beide macOS-targets verwijzen naar nightly-mac.yml. Vraag een van de drie om latest.yml of latest-mac.yml en je krijgt een 404 — er is geen stabiel kanaal, geen bèta-kanaal, en geen manier om je af te melden voor het kanaal dat wel bestaat. DeepSeeks eigen publicatienotities bevestigen de regeling in plaats van deze tegen te spreken: elke release publiceert een nightly-feed, en alleen stabiele releases publiceren een latest-feed die naar dezelfde artefacten wijst. "Nightly" is in deze context een kanaalnaam en geen build-cadans — de Windows- en Apple-silicon-feeds leveren beide dezelfde 0.2.1-rc.2-build, gedateerd 17 oktober, waarbij het Windows-pakket een tijdstempel van 09:22 UTC heeft en het Apple-silicon-pakket 09:57 UTC. Dus je krijgt de machinerie voor automatische updates, polling met jitter, backoff tot een maximum van één uur, en geen manier om iets anders op te vragen dan wat het previewkanaal op dat moment bevat.

GitHub maakt hetzelfde punt vanuit een andere invalshoek. De deepseek-ai/deepseek-harness-repository — 256.559 sterren en 30.921 forks toen er op 21 oktober 2026 werd gekeken — had op dezelfde datum 31 releases, allemaal gemarkeerd als prerelease, en allemaal zonder bijgevoegde binaire assets. Niets op de Releases-pagina is downloadbaar. Als je een build wilt, haal je die van download.deepseek.com of van npm, waar @deepseek-ai/dsh momenteel latest naar 0.2.1-rc.2 verwijst. De repository is een bron van waarheid voor de changelog en een dood spoor voor het artefact, wat ongewoon genoeg is om ronduit te zeggen, omdat de instinctieve reactie bij het zien van 31 releases is om op een daarvan een installer te verwachten.

Wat de installer schrijft, en wat hij weigert aan te raken

De Windows-installer is een native NSIS-pakket, geen wrapper rond een MSI, en gedraagt zich als zodanig. Je krijgt lichte, donkere en automatische paletten — selecteerbaar tijdens de installatie met /THEME=light, /THEME=dark of /THEME=auto — een bewerkbare doellocatie, en een installatiebereik dat beperkt is tot de huidige gebruiker. Stationshoofdmappen worden als doellocatie geweigerd, en een niet-lege doellocatie wordt alleen geaccepteerd als het al een geregistreerde installatie is; dat is de installer die weigert een niet-gerelateerde map te overschrijven. Bij een update wacht het stille pad maximaal tien seconden tot de draaiende applicatie is afgesloten en stopt dan met exitcode 2 als deze nog draait. Dat is een eerlijke fout in plaats van een beschadigde installatie, en het zal opduiken in elke gescripte implementatie die de app niet eerst afsluit.

De uninstaller trekt de grens die de meeste uninstallers verkeerd trekken. Hij verwijdert de Electron-userData-map, de productmap onder %APPDATA%, en de updatercache onder %LOCALAPPDATA%. Hij raakt de harness-home niet aan — ~/.dsh, of waar DSH_HOME ook naartoe wijst — die je sessies, instellingen, inloggegevens en plugins bevat. Het meegeven van --updated of /KEEP_APP_DATA behoudt ook de Electron-gegevens. Uninstalleren en opnieuw installeren is dus een ondersteunde manier om een kapot venster te herstellen zonder je werk te verliezen, en dat is een bewuste ontwerpkeuze en geen ongeluk.

De meegeleverde runtimes zijn het kennen waard, omdat ze groot zijn en buiten de app-map staan. Python met numpy, pandas, python-docx, python-pptx, openpyxl, Pillow, lxml en XlsxWriter, plus Node en pnpm, worden geïnstalleerd onder $DSH_HOME/dsh-runtimes/dsh-primary-runtime — normaal gesproken ~/.dsh/... op beide platformen — de eerste keer dat een workspace aangeeft ze nodig te hebben. Dat is waarom de schijfvoetafdruk na een week gebruik niet de schijfvoetafdruk na installatie is, en waarom een de-installatie die $DSH_HOME behoudt, ook enkele honderden megabytes aan runtimes behoudt.

Instellingen worden eenmalig bij het opstarten gelezen uit desktop/settings.json in de Electron userData-map, wat op Windows neerkomt op %APPDATA%\@deepseek-ai\dsh-desktop\desktop\settings.json en op macOS op ~/Library/Application Support/@deepseek-ai/dsh-desktop/desktop/settings.json. DSH_HOME verplaatst dit bestand niet — een punt dat het vermelden waard is, omdat dit het enige configuratieonderdeel is dat niet de variabele volgt die al het overige volgt. De update-instellingen in dat bestand zijn in milliseconden: intervalMs is standaard 600.000, en maxBackoffMs is standaard 3.600.000 en moet minstens intervalMs zijn. Jitter is standaard 0,2, wordt beperkt tot een bereik van nul tot één en heeft een ondergrens van één seconde, terwijl het nooit het backoff-plafond overschrijdt. Voor HTTP-verkeer voor updates geldt per verbinding een inactiviteitsdeadline van 60.000 milliseconden, maar een actieve download heeft geen deadline voor de totale duur — een langzame verbinding wordt niet halverwege een download afgebroken.

Het sluiten van het venster sluit de applicatie niet.

Op beide platformen wordt het venster verborgen door het te sluiten. Op macOS is dat Command-W; op Windows is dat de sluitknop, Alt-F4, of Sluiten vanuit de taakbalk. Windows vraagt om bevestiging voordat het de eerste keer verbergt en schrijft een background-close-confirmed-flag in de Electron userData-map, zodat het maar één keer vraagt en niet elke keer. Windows houdt ook gedurende de hele sessie een systeemvakpictogram bij. macOS levert helemaal geen menubalkpictogram mee, waardoor de verborgen toestand daar echt onzichtbaar is — de app draait, taken draaien, en niets op het scherm zegt dat, totdat je het opnieuw opent met dsh://open of via het systeemvak, afhankelijk van het platform.

Wat het verbergen overleeft, is het nuttige deel. Lopende taken blijven doorlopen en de volgende keer dat het venster wordt getoond, presenteert het hetzelfde document met dezelfde sessie, dezelfde concepten en dezelfde scrolpositie. Dit is ander gedrag dan bij een browsertabblad dat je sluit en opnieuw opent, en het is de reden dat de desktopversie überhaupt de moeite waard is als je werk langlopende agenttaken omvat: je kunt het venster sluiten en de taak laten afmaken.

Afsluiten is een aparte actie met een eigen logica. Voordat er wordt afgesloten, inspecteert de shell de Host op actieve agents, waaronder subagents en agents die op goedkeuring wachten, berichten in de wachtrij, jobs die lopen of worden gestopt, en geplande herinneringen die zijn ingesteld. Als geen van deze bestaat, wordt er stil afgesloten. Als er wel een bestaat, krijg je een native bevestigingsdialoog met de titel DeepSeek Harness afsluiten? en een van drie toelichtingen, afhankelijk van wat er is gevonden: taken worden onderbroken, geplande taken worden niet uitgevoerd, of beide. Een Host die nooit de status gereed heeft bereikt, kan geen taken zijn gestart, dus afsluiten in die staat gebeurt zonder vragen. Het onderscheid tussen "sluiten" en "afsluiten" is het hele punt van het ontwerp, en het geldt op beide platformen, ook al toont slechts één ervan je een blijvend pictogram.

Het dsh-commando, en de volgorde die ertoe doet

Het installatieprogramma kan dsh op je PATH zetten, waardoor je de CLI kunt uitvoeren tegen dezelfde harness-thuismap die de desktopapp gebruikt. De instelling is dsh-opdracht beheren…, en deze staat direct onder Controleren op updates… in het menu, met drie acties: Installeren, Repareren en Verwijderen. Op macOS schrijft het een launcher naar /usr/local/bin/dsh en vraagt het om beheerderstoestemming wanneer dat nodig is; op Windows registreert het de opdracht in de PATH van de huidige gebruiker.

Twee regels voor de volgorde zijn gemakkelijk over het hoofd te zien en vervelend om achteraf te ontdekken. De eerste: voer Verwijderen uit voordat u de desktopapplicatie verwijdert, omdat het verwijderprogramma de dsh-registratie niet verwijdert. Als u eerst de applicatie verwijdert, blijft u achter met een PATH-item dat naar een binair bestand verwijst dat niet meer bestaat. De tweede: als u de applicatie naar een andere locatie verplaatst, gebruikt u Herstellen op macOS of Installeren vanaf de nieuwe locatie op Windows, in plaats van ervan uit te gaan dat de registratie met de app meegaat.

Pluginbeheer voor het desktopprofiel kent zijn eigen complicatie. Omdat Electron exclusief eigenaar is van $DSH_HOME/profiles/desktop terwijl het draait, is installeren in dat profiel niet iets dat je doet terwijl de app open is. De ondersteunde volgorde is om de desktopapp één keer te starten, deze af te sluiten en vervolgens dsh plugin --profile desktop add <package> vanaf de opdrachtregel uit te voeren. Het pakket komt terecht in het desktopprofiel en is actief de volgende keer dat je het venster opent.

Wat de verpakking je al vertelt, is onvoltooid.

De sectie met bekende beperkingen in de README is ongewoon openhartig, en twee van de vermeldingen daarin zijn precies degene die jou als eerste zullen treffen.

• Aanmelden bij het account is niet verbonden. De knop Aanmelden is uitgeschakeld. In plaats daarvan opent de eerste start een welkomstvenster van 600 bij 700 met een formulier voor een API-sleutel; Opslaan en doorgaan schrijft de sleutel naar de opslag voor ontwikkelaarsreferenties, en Later instellen opent de echte werkruimte zonder er een op te slaan. Als u op Aanmelden drukt waar die verschijnt, wordt de geconfigureerde platformpagina in uw systeembrowser geopend, waarbij de Host de PKCE-uitwisseling en een tijdelijke loopback-callback beheert — de infrastructuur bestaat, de accountbinding niet. Reken er in de praktijk op dat u een sleutel meeneemt.

• Release-ondertekening en notarisatie staan vermeld als vereisten waarvoor de productie-releaseomgeving nodig is. Dat is de README die voorzichtig is, en het is ook een punt waarop een meting nuttiger is dan een zin. De gepubliceerde Windows-executable heeft een geldige Authenticode-handtekening met een extended-validation-keten: GlobalSign Root CA–R3, via de GlobalSign Code Signing Root R45 en de GlobalSign GCC R45 EV CodeSigning CA 2020, naar een leaf-certificaat dat is uitgegeven aan Hangzhou DeepSeek Artificial Intelligence Co., Ltd., met als rechtsgebied CN / Zhejiang / Hangzhou en met de bedrijfscategorie particuliere organisatie. De RFC-3161-tijdstempel op die handtekening luidt 2026-10-17T09:22:04Z, wat tot op een minuut overeenkomt met de releasedatum in de Windows-updatefeed, en de SHA-512-digest van het gedownloade bestand komt byte voor byte overeen met de hash die in die feed is gepubliceerd. Dus op Windows is de binary vandaag ondertekend, van een tijdstempel voorzien en hash-matchend, wat de README ook zegt over het feit dat het proces nog niet volledig is geprodutionaliseerd. De macOS-kant is een andere kwestie en daar hebben we de notarisatie niet geverifieerd; trek de Windows-uitkomst niet door naar de andere kant.

Crashrapporten, en één detail dat je moet weten

Crashrapporten worden geschreven als crash-<UTC time>-<source>.log, in ~/Library/Logs/DeepSeek Harness op macOS of een logsmap onder het Electron userData-pad op Windows, en de tien meest recente worden bewaard. Dat aantal bewaarde logbestanden is klein genoeg om ertoe te doen: als er herhaaldelijk iets misgaat en je een paar dagen niet kijkt, is het logbestand dat de eerste fout zou hebben verklaard verdwenen. Kopieer de map als je iets intermitterends aan het debuggen bent.

Het herstelpad voor een beschadigde configuratie is even specifiek. De shell hernoemt cordis.patch.yml naar cordis.patch.yml.bak-<timestamp> zonder het bestand te parsen, dus het blijft behouden in plaats van gerepareerd, en de app start met de standaardwaarden. Als je dat bestand handmatig hebt bewerkt, staan je wijzigingen in de .bak en die is nog steeds leesbaar.

Wat dit betekent voor het eerdere advies "geen desktopapp"

In augustus 2026 hebben we richtlijnen gepubliceerd dat de harness geen desktopapplicatie had en dat Windows-gebruikers de terminalbuild moesten gebruiken — dat was destijds correct en is nu verouderd. De terminalbuild werkt nog steeds en is nog steeds de juiste keuze voor een server, een container of alles wat via een script draait. Wat is veranderd, is dat de desktopbuild geen speelgoedwrapper is: hij beheert een afzonderlijk profiel, houdt taken in leven wanneer een venster wordt gesloten, werkt zichzelf bij en deelt status met de CLI op een manier die jou helpt. Als je de desktopbuild hebt uitgesteld omdat het eerdere artikel zei dat die niet bestond, is die reden nu vervallen.

De installatiestappen zelf komen aan bod in onze installatiehandleiding en worden hier bewust niet herhaald. Wat die handleiding je niet kan vertellen, is welke van de drie installatieprogramma's geen link op de downloadpagina heeft, welk doelplatform een release achterloopt, dat er geen stabiel updatekanaal is om je op te abonneren, en dat de Windows-binary is ondertekend ook al staat in de README dat ondertekening bij een toekomstige release hoort. Dat zijn de feiten die bepalen of de desktopbuild het juiste is om te installeren, en ze zijn de reden dat deze pagina apart bestaat.

Als je liever niets wilt installeren

Een harness installeren om één model te bereiken is een hoop extra ballast voor heel weinig werk, en de desktopapp is een preview met één updatekanaal en een Intel-build waar niemand naar linkt. Als je eigenlijk DeepSeek-V4.1-Flash wilt — het model dat de harness standaard gebruikt, hetzelfde model waarvoor de releaseopmerkingen van 0.2.1-rc.2 ondersteuning toevoegen — dan regelt een API-endpoint dat zonder installer, zonder profielmap en zonder tray-pictogram waarvan je moet onthouden dat het draait.

De vergelijking die moet worden gemaakt, is niet die van desktopapp tegenover API in het abstracte. Het gaat erom of het werk een agent wil die een werkruimte open kan houden terwijl het venster gesloten is, scripts op je machine kan uitvoeren en een sessie urenlang in leven kan houden — in dat geval zijn de verpakkingsproblemen hierboven het waard om mee te leven, en is de desktopbuild de enige manier om dat gedrag te krijgen — of dat het werk een stroom verzoeken is aan een model dat al ergens anders wordt geserveerd. Voor het tweede geval, de modelmap is de kortere route, en niets in dit artikel verandert dat.