DeepSeek Harness Desktop App: Vad installationsprogrammet faktiskt lägger på din dator

DeepSeek Harness-skrivbordsappen är ett Electron-skal runt samma webbgränssnitt som du får från npx @deepseek-ai/dsh web, och den levereras som tre plattformsspecifika installationsprogram för ett harness som för närvarande ligger på version 0.2.1-rc.2. Den beskrivningen låter avfärdande, och det är inte meningen. Att paketera ett fungerande gränssnitt i en skrivbordscontainer är en helgs arbete; att paketera det i en container som äger sin egen runtime-katalog, håller dina uppgifter vid liv när du stänger fönstret, uppdaterar sig själv i en kanal utan stabil utgåva och bevarar dina sessioner genom var och en av dessa operationer är den del som tar månader, och det är den del som är värd att läsa om. Om du vill köra DeepSeek-V4.1-Flash genom ett harness som lever i ett fönster i stället för i en terminal, är det här det bygget, och de intressanta frågorna handlar helt om vad som händer runt fönstret.

Två saker behöver sägas innan detaljerna. För det första ersätter den här artikeln vår tidigare vägledning om att det inte fanns någon skrivbordsapp – den vägledningen var korrekt när den skrevs i augusti 2026, och den är fel nu. För det andra är detta en offentlig förhandsversion, fortfarande märkt som sådan på DeepSeeks egen webbplats, och paketeringen har de ojämnheter som den beteckningen antyder. Installationsprogrammet fungerar. Distributionen runt det är tunnare än du skulle gissa.

Vad desktopbygget faktiskt är

Skrivbordsapplikationen är ett tunt Electron-lager vars uppgift är att starta en Host-process och peka ett fönster mot den. Fönstret bygger inte upp något eget chattgränssnitt: det laddar den paketerade webb-ingången som medföljer i appen på dsh-app://app/, och uppdateringsdialogerna du ser kommer från en andra medföljande origin på dsh-app://shell/. En underordnad Node-process startas i Electrons RunAsNode-läge för att starta den gemensamma profilköraren, och skalet vidarebefordrar HTTP till den autentiserade webbvärden och tar bort rubrikerna transfer-encoding, connection och keep-alive på vägen. Svar för plugin-paket markeras no-store, vilket är en liten detalj med en synlig konsekvens: ändra ett plugin och nästa omladdning visar ändringen.

Eftersom URL:en är dsh-app:// snarare än localhost, finns det ingen fast port att komma ihåg och ingen portkonflikt att kringgå. Desktop-Host lyssnar som standard på en port som tilldelas av operativsystemet. Om du behöver en specifik sådan kan du ställa in den via en webserver.config.portåsidosättning, men standardvärdet är medvetet inte en konstant, och Host binder till 127.0.0.1. Detta spelar roll om du har följt äldre instruktioner: numret 19387 som cirkulerade i installationsguider från augusti är inte desktop-porten, och om du behandlar det som det kommer du att leta efter en tjänst som inte finns där.

Versionslåsningen är strängare än den först verkar. Electron och @deepseek-ai/dsh har alltid exakt samma version — inte ett intervall, inte en kompatibel huvudversion — så en uppgradering av harnessen är en skrivbordsrelease, och det finns ingen kombination av en ny dsh och ett gammalt fönster som stöds. Electron-processen tar ett lås för en enda instans som gäller under processens livstid och äger exklusivt $DSH_HOME/profiles/desktop. Den exklusiviteten är verklig: CLI:t kan inte starta den profilen, och ett npm-installerat dsh kan inte ändra den. Det som de två installationerna faktiskt delar är det tillstånd som spelar roll för dig — sessioner, inställningar, autentiseringsuppgifter, arbetsytor och lagring, allt under $DSH_HOME. Det de inte delar är körbara paket, aktivering av plugin, låsfiler eller node_modules, vilket är anledningen till att det inte är samma operation att installera ett plugin i skrivbordsprofilen som att installera ett i CLI-profilen.

Tre installationsprogram, en uppdateringskanal, ingen stabil version

Tre installationsprogram finns och alla tre svarar. Den 64-bitars Windows-exekverbara filen är 289 385 456 byte och levereras med HTTP 200. Skivavbilden för Apple Silicon är 264 990 950 byte, också 200. Intel Mac-skivavbilden är 289 480 824 byte, också 200. Alla tre ändrades senast den 17 oktober 2026. Endast två av dem länkas från nedladdningssidan. Intel-bygget är live, är nåbart och har ingen länk som pekar på det någonstans på deepseek.com/en/harness/ – om du sitter på en Intel Mac och följde sidan skulle du rimligen dra slutsatsen att det inte fanns något bygge för dig.

Intel-bygget ligger också en version efter. Dess uppdateringsflöde listar 0.2.1-rc.1; flödena för Windows och Apple Silicon listar båda 0.2.1-rc.2. En releasekandidat är inte ett stort funktionsgap, men det är en tydlig signal om vilka mål som byggs först och vilka som verifieras sist, och det är precis sådant man vill veta innan man binder sina arbetssessioner till en plattform.

Uppdateringskanalerna är där distributionsberättelsen blir tunn. Flödena är per mål, under /dsh-desk/feeds/<target>/ på samma värd. Windows x64 löser upp nightly.yml; båda macOS-målen löser upp nightly-mac.yml. Frågar du någon av de tre efter latest.yml eller latest-mac.yml får du en 404 – det finns ingen stabil kanal, ingen betakanal och inget sätt att välja bort den som finns. DeepSeeks egna publiceringsanteckningar bekräftar arrangemanget snarare än motsäger det: varje utgåva publicerar ett nightly-flöde, och endast stabila utgåvor publicerar ett latest-flöde som pekar på samma artefakter. "Nightly" i det här sammanhanget är ett kanalnamn snarare än en byggtakt – både Windows- och Apple-silicon-flödena levererar samma 0.2.1-rc.2-bygge, daterat 17 oktober, där Windows-paketet har tidsstämpeln 09:22 UTC och Apple-silicon-paketet 09:57 UTC. Så du får maskineriet för automatisk uppdatering, jitterbaserad polling, backoff upp till ett tak på en timme, och inget sätt att begära något annat än det som förhandsgranskningskanalen för närvarande innehåller.

GitHub framför samma poäng ur en annan vinkel. deepseek-ai/deepseek-harness-förrådet – 256 559 stjärnor och 30 921 forks när det lästes den 21 oktober 2026 – hade 31 utgåvor samma datum, alla flaggade som förhandsversioner och alla med noll binära tillgångar bifogade. Ingenting på sidan Releases går att ladda ner. Om du vill ha en byggd version får du den från download.deepseek.com eller från npm, där @deepseek-ai/dsh för närvarande löser upp latest till 0.2.1-rc.2. Förrådet är en sanningskälla för ändringsloggen och en återvändsgränd för artefakten, vilket är tillräckligt ovanligt för att vara värt att säga rakt ut, eftersom instinkten när man ser 31 utgåvor är att förvänta sig ett installationsprogram på en av dem.

Vad installationsprogrammet skriver, och vad det vägrar röra

Windows-installationsprogrammet är ett inbyggt NSIS-paket, inte ett omslag runt en MSI, och det beter sig som ett sådant. Du får ljusa, mörka och automatiska paletter – valbara vid installation med /THEME=light, /THEME=dark eller /THEME=auto – en redigerbar målmapp och ett installationsomfång begränsat till den aktuella användaren. Enhetsrötter avvisas som mål, och en icke-tom målmapp accepteras endast om den redan är en registrerad installation, vilket innebär att installationsprogrammet vägrar skriva över en orelaterad mapp. Vid uppdatering väntar den tysta körningen upp till tio sekunder på att det körande programmet ska avslutas och avbryter sedan med slutkod 2 om det fortfarande körs. Det är ett ärligt misslyckande snarare än en skadad installation, och det kommer att märkas i alla skriptade driftsättningar som inte avslutar appen först.

Avinstalleraren drar gränsen där de flesta avinstallerare gör fel. Den tar bort Electron userData-katalogen, produktkatalogen under %APPDATA%, och uppdateringscachen under %LOCALAPPDATA%. Den rör inte harness-hemkatalogen – ~/.dsh, eller var DSH_HOME än pekar – som innehåller dina sessioner, inställningar, inloggningsuppgifter och plugin. Om du anger --updated eller /KEEP_APP_DATA behålls även Electron-datan. Så att avinstallera och installera om är ett sätt som stöds för att laga ett trasigt fönster utan att förlora ditt arbete, och det är ett medvetet designbeslut snarare än en slump.

De medföljande körtidsmiljöerna är värda att känna till eftersom de är stora och ligger utanför appkatalogen. Python med numpy, pandas, python-docx, python-pptx, openpyxl, Pillow, lxml och XlsxWriter, plus Node och pnpm, installeras under $DSH_HOME/dsh-runtimes/dsh-primary-runtime — normalt ~/.dsh/... på båda plattformarna — första gången en arbetsyta deklarerar att den behöver dem. Det är därför diskutrymmet efter en veckas användning inte är detsamma som diskutrymmet efter installation, och därför bevarar en avinstallation som behåller $DSH_HOME också flera hundra megabyte körtidsmiljöer.

Inställningarna läses en gång vid start från desktop/settings.json i userData-katalogen för Electron, vilket i Windows innebär %APPDATA%\@deepseek-ai\dsh-desktop\desktop\settings.json och i macOS innebär ~/Library/Application Support/@deepseek-ai/dsh-desktop/desktop/settings.json. DSH_HOME flyttar inte den här filen – en punkt värd att lyfta fram, eftersom det är den enda konfigurationsdelen som inte följer variabeln som allt annat följer. Uppdateringsinställningarna i den filen anges i millisekunder: intervalMs har standardvärdet 600 000, och maxBackoffMs har standardvärdet 3 600 000 och måste vara minst intervalMs. Jitter har standardvärdet 0,2, begränsas till intervallet noll till ett och har en nedre gräns på en sekund samtidigt som det aldrig överskrider backoff-taket. En tidsgräns för inaktivitet per anslutning på 60 000 millisekunder gäller för HTTP-trafik för uppdateringar, men en aktiv nedladdning har ingen tidsgräns för total varaktighet – en långsam länk klipps inte av mitt i nedladdningen.

Att stänga fönstret stänger inte programmet.

På båda plattformarna döljer stängning av fönstret det. På macOS är det Command-W; på Windows är det stängningsknappen, Alt-F4, eller Stäng i aktivitetsfältet. Windows begär en bekräftelse före den första döljningen och skriver en background-close-confirmed-flagga under Electron userData-katalogen så att den frågar en gång och inte varje gång. Windows behåller också en tray-ikon under hela körningen. macOS har ingen menyradsikon alls, vilket gör det dolda läget verkligen osynligt där — appen körs, uppgifter körs och inget på skärmen säger det förrän du öppnar den igen med dsh://open eller tray-ikonen, beroende på plattform.

Det som överlever att fönstret döljs är det användbara. Pågående uppgifter fortsätter att köras, och nästa gång fönstret visas presenterar det samma dokument med samma session, samma utkast och samma scrollposition. Detta är ett annat beteende än en webbläsarflik som du stänger och öppnar igen, och det är anledningen till att desktopversionen är värd att ha över huvud taget om ditt arbete innefattar långkörande agentuppgifter: du kan stänga fönstret och låta uppgiften slutföras.

Att avsluta är en separat åtgärd med sin egen logik. Innan avslutningen undersöker skalet Host efter körande agenter, inklusive underagenter och agenter som väntar på godkännande, köade meddelanden, jobb som körs eller stoppas, och schemalagda påminnelser som är aktiverade. Om inget av dessa finns avslutas det tyst. Om något av dem finns får du en inbyggd bekräftelsedialog med titeln Avsluta DeepSeek Harness? med en av tre förklaringar beroende på vad den hittade: uppgifter kommer att avbrytas, schemalagda uppgifter kommer inte att köras, eller båda. En Host som aldrig nådde redo kan inte ha startat några uppgifter, så avslutning i det tillståndet sker utan att fråga. Åtskillnaden mellan "stäng" och "avsluta" är hela poängen med designen, och den gäller på båda plattformarna även om bara en av dem visar dig en beständig ikon.

Kommandot dsh, och ordningen som spelar roll

Installationsprogrammet kan lägga dsh i din PATH, vilket är det som gör att du kan köra CLI:t mot samma harness-hem som skrivbordsappen använder. Kontrollen är Hantera dsh-kommando…, och den ligger direkt under Sök efter uppdateringar… i menyn, med tre åtgärder: Installera, Reparera och Ta bort. På macOS skriver den en startare på /usr/local/bin/dsh och begär administratörsbehörighet när det behövs; på Windows registrerar den kommandot i den aktuella användarens PATH.

Två regler för ordningsföljden är lätta att missa och irriterande att upptäcka i efterhand. Den första: kör Ta bort innan du avinstallerar skrivbordsapplikationen, eftersom avinstallationsprogrammet inte tar bort dsh-registreringen. Avinstallerar du först lämnas du med en PATH-post som pekar på en binärfil som inte längre finns. Den andra: om du flyttar programmet till en annan plats, använd Reparera på macOS eller Installera från den nya platsen på Windows, i stället för att anta att registreringen följer med appen.

Pluginhantering för desktop-profilen har en egen liten hake. Eftersom Electron exklusivt äger $DSH_HOME/profiles/desktop medan den körs, är installation i den profilen inget man gör med appen öppen. Det rekommenderade tillvägagångssättet är att starta desktopappen en gång, avsluta den och sedan köra dsh plugin --profile desktop add <package> från kommandoraden. Paketet hamnar i desktop-profilen och är aktivt nästa gång du öppnar fönstret.

Det som förpackningen redan säger dig är ofullständigt

README-filens avsnitt om kända begränsningar är ovanligt uppriktigt, och två av dess punkter är de som kommer att påverka dig först.

• Kontoinloggning är inte ansluten. Knappen Logga in är inaktiverad. I stället öppnar den första körningen ett välkomstfönster på 600 × 700 med ett formulär för API-nyckel; Spara och fortsätt skriver nyckeln till utvecklingsmiljöns autentiseringsuppgiftslager, och Konfigurera senare öppnar den riktiga arbetsytan utan att spara någon. Om du trycker på Logga in där det visas öppnas den konfigurerade plattformssidan i systemwebbläsaren, där Host ansvarar för PKCE-utbytet och ett tillfälligt loopback-återanrop – mekanismerna finns, men kontobindningen saknas. I praktiken bör du räkna med att ta med en nyckel.

• Releasesignering och notarisering anges kräva produktionsmiljön för releaser. Det är README som är försiktig, och det är också där en mätning är mer användbar än en mening. Den publicerade Windows-körbara filen har en giltig Authenticode-signatur med en kedja för utökad validering: GlobalSign Root CA–R3, ned genom GlobalSign Code Signing Root R45 och GlobalSign GCC R45 EV CodeSigning CA 2020, till ett lövcertifikat utfärdat till Hangzhou DeepSeek Artificial Intelligence Co., Ltd. med jurisdiktion angiven som CN / Zhejiang / Hangzhou och en verksamhetskategori för privat organisation. RFC-3161-tidsstämpeln på signaturen anger 2026-10-17T09:22:04Z, vilket matchar utgivningsdatumet i Windows-uppdateringsflödet inom en minut, och SHA-512-digesten för den nedladdade filen matchar hashen som publicerats i det flödet byte för byte. Så på Windows är binärfilen signerad, tidsstämplad och hashmatchad i dag, oavsett vad README säger om att processen inte är fullt produktionssatt. macOS-sidan är en annan fråga och vi verifierade inte notarisering där; överför inte Windows-resultatet dit.

Kraschrapporter, och en detalj värd att känna till

Kraschrapporter skrivs som crash-<UTC time>-<source>.log till ~/Library/Logs/DeepSeek Harness på macOS eller en logs-katalog under Electron userData-sökväg på Windows, och de tio senaste behålls. Det är ett så litet antal att det spelar roll: om något går fel upprepade gånger och du inte tittar på några dagar är loggen som skulle ha förklarat det första felet borta. Kopiera katalogen om du felsöker något som är intermittent.

Återställningsvägen för en skadad konfiguration är lika specifik. Skalet byter namn på cordis.patch.yml till cordis.patch.yml.bak-<timestamp> utan att tolka den, så filen bevaras i stället för att repareras, och appen startar med standardvärden. Om du har redigerat filen för hand är .bak där dina ändringar hamnade, och den är fortfarande läsbar.

Vad detta innebär för det tidigare rådet "ingen skrivbordsapp"

I augusti 2026 publicerade vi vägledning om att harness inte hade någon skrivbordsapplikation och att Windows-användare borde köra terminalbygget – det var korrekt då och är nu föråldrat. Terminalbygget fungerar fortfarande och är fortfarande rätt val för en server, en container eller allt som skriptas. Det som har ändrats är att skrivbordsbygget inte är ett leksaksskal: det har en egen separat profil, håller uppgifter vid liv även när fönstret stängs, uppdaterar sig själv och delar tillstånd med CLI:t åt det håll som hjälper dig. Om du sköt upp skrivbordsbygget eftersom den tidigare artikeln sa att det inte fanns, är det skälet borta.

Själva installationsstegen tas upp i vår installationsgenomgång och upprepas medvetet inte här. Det som genomgången inte kan tala om är vilket av de tre installationsprogrammen som saknar länk på nedladdningssidan, vilket mål som ligger en utgåva efter, att det inte finns någon stabil uppdateringskanal att välja, och att Windows-binären är signerad trots att README säger att signering hör till en framtida utgåva. Det är fakta som avgör om skrivbordsbygget är rätt sak att installera, och de är anledningen till att den här sidan finns separat.

Om du hellre inte vill installera något

Att installera en harness för att nå en enda modell är en stor yta för ett litet arbete, och skrivbordsappen är en förhandsversion med en enda uppdateringskanal och en Intel-build som ingen länkar till. Om det du faktiskt vill ha är DeepSeek-V4.1-Flash – modellen som harnessen använder som standard, samma som versionsanteckningarna för 0.2.1-rc.2 lägger till stöd för – så klarar en API-slutpunkt det utan installationsprogram, utan profilkatalog och utan en meddelandefältsikon som du måste komma ihåg är igång.

Jämförelsen som bör göras är inte skrivbordsappen mot API:et i abstrakt mening. Det handlar om huruvida arbetet vill ha en agent som kan hålla en arbetsyta öppen över ett stängt fönster, köra skript på din dator och hålla en session vid liv i timmar – i så fall är paketeringsproblemen ovan värda att stå ut med, och skrivbordsbygget är det enda sättet att få det beteendet – eller om arbetet är en ström av förfrågningar till en modell som redan serveras någon annanstans. För det andra fallet, modellkatalogen är den kortare vägen, och det finns inget i den här artikeln som ändrar det.