App desktop DeepSeek Harness: cosa il programma di installazione mette davvero sulla tua macchina

L'app desktop DeepSeek Harness è una shell Electron che avvolge la stessa interfaccia web che ottieni da npx @deepseek-ai/dsh web, e viene distribuita come tre installer specifici per piattaforma per un harness che al momento si trova alla versione 0.2.1-rc.2. Questa descrizione può sembrare riduttiva, e non vuole esserlo. Racchiudere un'interfaccia funzionante in un contenitore desktop è un lavoro da fine settimana; racchiuderla in un contenitore che possiede la propria directory di runtime, mantiene attive le tue attività quando chiudi la finestra, si aggiorna da solo su un canale senza release stabili e conserva le tue sessioni attraverso ognuna di queste operazioni è la parte che richiede mesi, ed è la parte che vale la pena leggere. Se vuoi eseguire DeepSeek-V4.1-Flash tramite un harness che vive in una finestra anziché in un terminale, questa è quella build, e le domande interessanti riguardano tutte ciò che accade attorno alla finestra.

Due cose vanno dette prima dei dettagli. In primo luogo, questo articolo sostituisce la nostra precedente indicazione secondo cui non esisteva un'app desktop: tale indicazione era corretta quando è stata scritta nell'agosto 2026, e ora è sbagliata. In secondo luogo, questa è un'anteprima pubblica, ancora etichettata come tale sul sito di DeepSeek, e il pacchetto presenta gli spigoli tipici che quell'etichetta implica. L'installer funziona. La distribuzione attorno ad esso è più scarna di quanto potresti immaginare.

Che cos'è realmente la build desktop

L'applicazione desktop è un sottile livello Electron il cui compito è avviare un processo Host e puntare una finestra su di esso. La finestra non dispone di un'interfaccia chat propria: carica il punto di ingresso Web pacchettizzato incluso nell'app all'indirizzo dsh-app://app/, e le finestre di dialogo di aggiornamento che vedrai provengono da una seconda origine inclusa nell'app all'indirizzo dsh-app://shell/. Un processo Node figlio viene avviato in modalità RunAsNode di Electron per avviare il runner del profilo condiviso, e la shell inoltra HTTP al Web Host autenticato, rimuovendo gli header transfer-encoding, connection e keep-alive durante il passaggio. Le risposte dei bundle dei plugin sono contrassegnate come no-store, un piccolo dettaglio con una conseguenza visibile: modifica un plugin e il successivo ricaricamento mostrerà la modifica.

Poiché l'URL è dsh-app:// anziché localhost, non c'è alcuna porta fissa da ricordare e nessun conflitto di porte da aggirare. L'Host desktop è in ascolto su una porta assegnata dal sistema operativo per impostazione predefinita. Se ne hai bisogno di una specifica, puoi impostarla tramite un override webserver.config.port, ma per scelta l'impostazione predefinita non è una costante, e l'Host si associa a 127.0.0.1. Questo è importante se hai seguito istruzioni più vecchie: il numero 19387 che circolava nelle guide all'installazione di agosto non è la porta desktop, e trattarlo come tale ti porterà a cercare un servizio che non c'è.

Il pinning delle versioni è più rigido di quanto sembri a prima vista. Electron e @deepseek-ai/dsh hanno sempre esattamente la stessa versione — non un range, non una major compatibile — quindi un aggiornamento dell'harness è un rilascio desktop, e non esiste una combinazione supportata di un nuovo dsh e di una vecchia finestra. Il processo Electron acquisisce un lock di istanza singola per l'intera durata del processo e possiede in esclusiva $DSH_HOME/profiles/desktop. Questa esclusività è reale: la CLI non può avviare quel profilo, e un'installazione npm di dsh non può modificarlo. Ciò che le due installazioni condividono è lo stato che conta per te — sessioni, impostazioni, credenziali, workspace e storage, tutti sotto $DSH_HOME. Ciò che non condividono sono i pacchetti eseguibili, l'attivazione dei plugin, i lockfile o node_modules, motivo per cui installare un plugin nel profilo desktop non è la stessa operazione che installarlo nel profilo CLI.

Tre installer, un unico canale di aggiornamento, nessuna versione stabile

Tre installer esistono e tutti e tre rispondono. L'eseguibile Windows a 64 bit è di 289.385.456 byte ed è stato restituito con HTTP 200. L'immagine disco per Apple Silicon è di 264.990.950 byte, anch'essa 200. L'immagine disco per Mac Intel è di 289.480.824 byte, anch'essa 200. Tutti e tre sono stati modificati l'ultima volta il 17 ottobre 2026. Solo due di essi sono collegati dalla pagina di download. La build Intel è attiva, raggiungibile e non c'è alcun link che vi punti da nessuna parte su deepseek.com/en/harness/ — se usi un Mac Intel e hai seguito la pagina, concluderesti ragionevolmente che non esisteva una build per te.

Anche la build Intel è indietro di una versione. Il suo feed di aggiornamento riporta 0.2.1-rc.1; i feed Windows e Apple silicon riportano entrambi 0.2.1-rc.2. Una release candidate non è un grande divario in termini di funzionalità, ma è un segnale concreto di quali target vengono compilati per primi e quali vengono verificati per ultimi, ed è esattamente il tipo di informazione che vuoi conoscere prima di affidare le tue sessioni di lavoro a una piattaforma.

I canali di aggiornamento sono il punto in cui il quadro della distribuzione si fa lacunoso. I feed sono per target, sotto /dsh-desk/feeds/<target>/ sullo stesso host. Windows x64 risolve nightly.yml; entrambi i target macOS risolvono nightly-mac.yml. Chiedendo a uno qualsiasi dei tre latest.yml o latest-mac.yml si ottiene un 404 — non esiste un canale stabile, né un canale beta, né un modo per rinunciare a quello che esiste. Le note di pubblicazione di DeepSeek confermano l'assetto anziché contraddirlo: ogni release pubblica un feed nightly, e solo le release stabili pubblicano un feed latest che punta agli stessi artefatti. In questo contesto, "Nightly" è il nome di un canale anziché una cadenza di build — i feed Windows e Apple silicon servono entrambi la stessa build 0.2.1-rc.2, datata 17 ottobre, con il pacchetto Windows con timestamp 09:22 UTC e il pacchetto Apple silicon 09:57 UTC. Quindi si ottiene il meccanismo di aggiornamento automatico, polling con jitter, backoff fino a un limite massimo di un'ora e nessun modo per chiedere qualcosa di diverso da ciò che il canale di anteprima contiene attualmente.

GitHub arriva allo stesso punto da un'angolazione diversa. Il deepseek-ai/deepseek-harness repository — 256.559 stelle e 30.921 fork al momento della lettura, il 21 ottobre 2026 — aveva 31 release alla stessa data, ognuna contrassegnata come prerelease e ognuna con zero asset binari allegati. Nulla nella pagina Releases è scaricabile. Se vuoi una build, la ottieni da download.deepseek.com oppure da npm, dove @deepseek-ai/dsh attualmente risolve latest alla versione 0.2.1-rc.2. Il repository è una fonte di verità per il changelog e un vicolo cieco per l'artefatto, il che è abbastanza insolito da meritare di essere detto chiaramente, perché l'istinto, vedendo 31 release, è quello di aspettarsi un installer su una di esse.

Ciò che l'installer scrive e ciò che rifiuta di toccare

Il programma di installazione di Windows è un pacchetto NSIS nativo, non un wrapper attorno a un MSI, e si comporta come tale. Sono disponibili palette chiare, scure e automatiche — selezionabili al momento dell'installazione con /THEME=light, /THEME=dark o /THEME=auto — una directory di destinazione modificabile e un ambito di installazione limitato all'utente corrente. Le radici delle unità vengono rifiutate come destinazioni e una destinazione non vuota viene accettata solo se è già un'installazione registrata, il che significa che il programma di installazione rifiuta di sovrascrivere una cartella non correlata. In fase di aggiornamento, il percorso silenzioso attende fino a dieci secondi l'uscita dell'applicazione in esecuzione e poi si arresta con codice di uscita 2 se è ancora in esecuzione. Si tratta di un errore onesto anziché di un'installazione danneggiata, e comparirà in qualsiasi distribuzione tramite script che non chiuda prima l'app.

Il disinstallatore traccia il confine che la maggior parte dei disinstallatori sbaglia. Rimuove la directory userData di Electron, la directory del prodotto in %APPDATA% e la cache dell'updater in %LOCALAPPDATA%. Non tocca la home dell'harness — ~/.dsh, o qualunque percorso DSH_HOME indichi — che contiene le tue sessioni, impostazioni, credenziali e plugin. Se si passa --updated o /KEEP_APP_DATA si conservano anche i dati di Electron. Quindi disinstallare e reinstallare è un modo supportato per risolvere una finestra rotta senza perdere il tuo lavoro, e questa è una decisione progettuale deliberata, non un caso.

I runtime inclusi vale la pena conoscerli perché sono di grandi dimensioni e risiedono al di fuori della directory dell'app. Python con numpy, pandas, python-docx, python-pptx, openpyxl, Pillow, lxml e XlsxWriter, oltre a Node e pnpm, vengono installati in $DSH_HOME/dsh-runtimes/dsh-primary-runtime — normalmente ~/.dsh/... su entrambe le piattaforme — la prima volta che un workspace dichiara di averne bisogno. Ecco perché l'occupazione su disco dopo una settimana di utilizzo non è quella successiva all'installazione, e perché una disinstallazione che conserva $DSH_HOME conserva anche diverse centinaia di megabyte di runtime.

Le impostazioni vengono lette una sola volta all'avvio da desktop/settings.json all'interno della directory userData di Electron, che su Windows significa %APPDATA%\@deepseek-ai\dsh-desktop\desktop\settings.json e su macOS significa ~/Library/Application Support/@deepseek-ai/dsh-desktop/desktop/settings.json. DSH_HOME non sposta questo file — un punto che vale la pena segnalare, perché è l'unico elemento di configurazione che non segue la variabile che tutto il resto segue. Le impostazioni di aggiornamento in quel file sono in millisecondi: intervalMs è predefinito a 600.000, e maxBackoffMs è predefinito a 3.600.000 e deve essere almeno intervalMs. Il jitter è predefinito a 0,2, viene limitato a un intervallo da zero a uno e ha un valore minimo di un secondo senza mai superare il limite di backoff. Una scadenza di inattività per connessione di 60.000 millisecondi si applica al traffico HTTP degli aggiornamenti, sebbene un download attivo non abbia una scadenza di durata totale — un collegamento lento non verrà interrotto a metà download.

Chiudere la finestra non chiude l'applicazione

Su entrambe le piattaforme, chiudere la finestra la nasconde. Su macOS si usa Command-W; su Windows si usa il pulsante di chiusura, Alt-F4, oppure Chiudi dalla barra delle applicazioni. Windows chiede una conferma prima del primo nascondimento e scrive un flag background-close-confirmed nella directory userData di Electron, così lo chiede una volta sola e non ogni volta. Windows mantiene anche un'icona nella tray per tutta l'esecuzione. macOS non fornisce alcuna icona nella barra dei menu, il che rende lo stato nascosto davvero invisibile: l'app è in esecuzione, le attività sono in esecuzione e nulla sullo schermo lo indica finché non la riapri con dsh://open o dalla tray, a seconda della piattaforma.

Ciò che sopravvive al nascondimento è la parte utile. Le attività in esecuzione continuano a funzionare e, la prossima volta che la finestra viene mostrata, presenta lo stesso documento con la stessa sessione, le stesse bozze e la stessa posizione di scorrimento. Questo è un comportamento diverso da quello di una scheda del browser che chiudi e riapri, ed è il motivo per cui la versione desktop vale davvero la pena di averla se il tuo lavoro implica attività di agenti di lunga durata: puoi chiudere la finestra e lasciare che l'attività termini.

L'uscita è un'azione separata con una logica propria. Prima di uscire, la shell ispeziona l'Host per verificare la presenza di agenti in esecuzione, inclusi subagenti e agenti in attesa di approvazione, messaggi in coda, job in esecuzione o in arresto e promemoria pianificati attivi. Se non esiste nessuno di questi elementi, esce silenziosamente. Se ne esiste almeno uno, viene visualizzata una finestra di dialogo di conferma nativa intitolata Uscire da DeepSeek Harness? con una delle tre spiegazioni a seconda di ciò che ha rilevato: le attività verranno interrotte, le attività pianificate non verranno eseguite oppure entrambe le cose. Un Host che non ha mai raggiunto lo stato pronto non può aver avviato alcuna attività, quindi uscire in quello stato procede senza chiedere. La distinzione tra "chiudi" e "esci" è l'intero punto del design, e vale su entrambe le piattaforme anche se solo una di esse mostra un'icona persistente.

Il comando dsh e l'ordine che conta

L'installatore può mettere dsh nel tuo PATH, il che ti consente di eseguire la CLI nella stessa home dell'harness usata dall'app desktop. Il controllo è Gestisci comando dsh… e si trova subito sotto Verifica aggiornamenti… nel menu, con tre azioni: Installa, Ripara e Rimuovi. Su macOS scrive un launcher in /usr/local/bin/dsh e richiederà l'autorizzazione dell'amministratore quando necessario; su Windows registra il comando nel PATH dell'utente corrente.

Due regole di sequenza sono facili da trascurare e fastidiose da scoprire in seguito. La prima: esegui Remove prima di disinstallare l'applicazione desktop, perché il disinstallatore non rimuove la registrazione di dsh. Se disinstalli prima, ti ritrovi con una voce PATH che punta a un binario che non esiste più. La seconda: se sposti l'applicazione in un'altra posizione, usa Repair su macOS o Install dalla nuova posizione su Windows, invece di dare per scontato che la registrazione segua l'app.

La gestione dei plugin per il profilo desktop presenta una sua peculiarità. Poiché Electron possiede in esclusiva $DSH_HOME/profiles/desktop mentre è in esecuzione, installare in quel profilo non è qualcosa che si fa con l'app aperta. La procedura supportata consiste nell'avviare l'app desktop una volta, chiuderla e poi eseguire dsh plugin --profile desktop add <package> dalla riga di comando. Il pacchetto viene inserito nel profilo desktop ed è attivo la prossima volta che apri la finestra.

Quello che il packaging ti dice già è incompleto

La sezione sulle limitazioni note del README è insolitamente schietta, e due delle sue voci sono proprio quelle con cui avrai a che fare per prime.

• L'accesso all'account non è connesso. Il pulsante Accedi è disabilitato. Al suo posto, al primo avvio si apre una finestra di benvenuto di 600 x 700 con un modulo per la chiave API; Salva e continua scrive la chiave nell'archivio delle credenziali di sviluppo, mentre Configura più tardi apre l'area di lavoro reale senza salvarne alcuna. Premendo Accedi, dove compare, si apre nel browser di sistema la pagina della piattaforma configurata, con l'Host che gestisce lo scambio PKCE e un callback di loopback temporaneo — l'infrastruttura esiste, il collegamento all'account no. In pratica, prevedi di procurarti una chiave.

• La firma e la notarizzazione della release sono elencate come operazioni che richiedono l'ambiente di release di produzione. È il README che usa cautela, ed è anche il punto in cui una misurazione è più utile di una frase. L'eseguibile Windows pubblicato porta una firma Authenticode valida con una catena a validazione estesa: GlobalSign Root CA–R3, fino alla GlobalSign Code Signing Root R45 e alla GlobalSign GCC R45 EV CodeSigning CA 2020, fino a un certificato foglia rilasciato a Hangzhou DeepSeek Artificial Intelligence Co., Ltd. con giurisdizione indicata come CN / Zhejiang / Hangzhou e categoria di attività di organizzazione privata. Il timestamp RFC-3161 su quella firma riporta 2026-10-17T09:22:04Z, che corrisponde alla data di rilascio nel feed di aggiornamento di Windows con uno scarto inferiore al minuto, e il digest SHA-512 del file scaricato corrisponde byte per byte all'hash pubblicato in quel feed. Quindi su Windows il binario oggi è firmato, dotato di timestamp e con hash corrispondente, indipendentemente da ciò che dice il README sul fatto che il processo non sia completamente portato in produzione. Il lato macOS è una questione diversa e lì non abbiamo verificato la notarizzazione; non estendere il risultato di Windows.

Report di crash e un dettaglio che vale la pena conoscere

I rapporti di crash vengono scritti come crash-<UTC time>-<source>.log, in ~/Library/Logs/DeepSeek Harness su macOS o una directory logs sotto il percorso userData di Electron su Windows, e vengono mantenuti i dieci più recenti. Quel limite di conservazione è abbastanza basso da avere importanza: se qualcosa va storto ripetutamente e non controlli per qualche giorno, il log che avrebbe spiegato il primo errore non c'è più. Copia la directory se stai eseguendo il debug di qualcosa di intermittente.

Il percorso di recupero per una configurazione danneggiata è altrettanto specifico. La shell rinomina cordis.patch.yml in cordis.patch.yml.bak-<timestamp> senza analizzarlo, quindi il file viene conservato anziché riparato, e l'app si avvia con i valori predefiniti. Se hai modificato manualmente quel file, le tue modifiche sono finite nel .bak, che è ancora leggibile.

Dove ci lascia il precedente consiglio «niente app desktop»

Ad agosto 2026 abbiamo pubblicato un'indicazione secondo cui l'harness non aveva un'applicazione desktop e che gli utenti Windows avrebbero dovuto usare la build da terminale: all'epoca era accurata e ora è obsoleta. La build da terminale funziona ancora ed è tuttora la scelta giusta per un server, un container o qualsiasi cosa scriptata. Quello che è cambiato è che la build desktop non è un wrapper giocattolo: gestisce un profilo separato, mantiene le attività attive anche alla chiusura di una finestra, si aggiorna da sola e condivide lo stato con la CLI nella direzione che ti è utile. Se stavi rimandando la build desktop perché l'articolo precedente diceva che non esisteva, quel motivo è venuto meno.

I passaggi di installazione sono già illustrati nella nostra guida all'installazione e non vengono ripetuti qui, di proposito. Ciò che quella guida non può dirti è quale dei tre installer non ha un link nella pagina di download, quale target è indietro di una release, che non esiste un canale di aggiornamento stabile a cui aderire e che il binario di Windows è firmato anche se il README afferma che la firma appartiene a una release futura. Sono questi i fatti che determinano se la build desktop sia la cosa giusta da installare, ed è per questo che questa pagina esiste separatamente.

Se preferisci non installare nulla

Installare un harness per raggiungere un solo modello comporta molta superficie per una piccola quantità di lavoro, e l'app desktop è una preview con un unico canale di aggiornamento e una build Intel a cui nessuno rimanda. Se ciò che vuoi davvero è DeepSeek-V4.1-Flash — il modello predefinito dell'harness, lo stesso per cui le note di 0.2.1-rc.2 aggiungono il supporto — un endpoint API lo fa senza installer, senza directory del profilo e senza icona nella tray che devi ricordarti sia in esecuzione.

Il confronto da fare non è tra un'app desktop e un'API in astratto. È se il lavoro richieda un agente che possa tenere aperto uno spazio di lavoro anche a finestra chiusa, eseguire script sul tuo computer e mantenere viva una sessione per ore — nel qual caso vale la pena sopportare i problemi di packaging di cui sopra, e la build desktop è l'unico modo per ottenere quel comportamento — oppure se il lavoro sia un flusso di richieste a un modello già servito altrove. Nel secondo caso, la directory dei modelli è la strada più breve, e non c'è nulla in questo articolo che lo cambi.