DeepSeek Harness node-pty-Upgrade: Mac erneut testen

DeepSeek Harness befindet sich laut Projekt-Repository weiterhin in einer Developer Preview. Das Repository weist ausdrücklich auf schnell laufende Änderungen und mögliche Kompatibilitätsbrüche hin. (github.com) Für rc.7 sind deshalb drei Aussagen sauber zu trennen:

1. Bestätigt: Die Version wurde am 17.08.2026 veröffentlicht.
2. Bestätigt: node-pty wurde auf eine 1.2-Beta-Version aktualisiert.
3. Nicht bestätigt: Welche macOS-Versionen, Shell-Profile, Node-Laufzeiten und Langzeitprozesse dadurch zuverlässig abgedeckt sind.

node-pty stellt Bindings für Pseudoterminals bereit. Die Upstream-Dokumentation beschreibt Lese- und Schreibzugriffe, Terminalgrößenänderungen und die Ausführung von Programmen, die ein echtes Terminal erwarten. macOS gehört zu den unterstützten Plattformen. (github.com)

Für Ihre Entscheidung bedeutet das: Die Änderung liegt unterhalb der sichtbaren Web-Oberfläche. Sie kann beeinflussen, wie Eingaben an Bash gelangen, wie Terminaldaten gelesen werden oder wie Terminalzustände behandelt werden. Sie ersetzt aber keine Prüfung der gesamten Kette:

• DeepSeek-Harness-Version und Paketauflösung
• Node-Laufzeit und native Erweiterung
• Bash-Umgebung, Pfad und Shell-Initialisierung
• PTY-Eingabe und fortlaufende Ausgabe
• Signalweitergabe beim Abbruch
• Browser-, Netzwerk- und Sitzungszustand
• tatsächlicher Status des gestarteten Unterprozesses

Achtung: Schreiben Sie „bessere PTY-Kompatibilität“ nicht in ein Betriebsprotokoll als „alle Terminalprobleme behoben“. Die Release-Formulierung ist ein Ziel und eine Änderungsbeschreibung, kein allgemeiner Stabilitätsnachweis.

Beginnen Sie mit dem kleinsten Test, der den vollständigen Eingabe-Ausgabe-Kreislauf abbildet. Ein bloßer Befehl wie pwd reicht dafür nicht aus. Er kann erfolgreich sein, obwohl Echo, Folgeeingaben oder der Abschlussstatus fehlerhaft verarbeitet werden.

Führen Sie auf dem identischen entfernten Mac und im identischen Arbeitsverzeichnis eine kurze Testsequenz aus:

printf 'start\n'
printf 'input-test> '
read value
printf 'received=%s\n' "$value"
false
printf 'exit-after-false=%s\n' "$?"

Prüfen Sie dabei:

• Wird jede Eingabe sichtbar zurückgespiegelt?
• Erscheint die Ausgabe in der richtigen Reihenfolge?
• Bleibt die Sitzung nach read bedienbar?
• Wird der Exit-Code von false korrekt erkannt?
• Kann danach noch ein weiterer Befehl ausgeführt werden?
• Gibt es einen Unterschied zwischen einem neuen Bash-Prozess und einer persistenten Sitzung?

Die Release-Notiz nennt ausdrücklich eine Korrektur für persistente Bash-Latenz im Minimalmodus. Das ist relevant, aber nicht gleichbedeutend mit einer Korrektur jeder Verzögerung. Die Wartezeit kann auch in der Modellentscheidung, der WebSocket-Übertragung, der Ausgabe-Pufferung oder der Shell-Initialisierung entstehen.

Dokumentieren Sie daher nicht nur „schneller“ oder „langsamer“. Notieren Sie die beobachtete Stelle:

• Verzögerung vor dem Echo
• Verzögerung nach dem Absenden
• Ausgabe kommt stoßweise
• Befehl läuft, aber die Oberfläche wirkt blockiert
• Ausgabe endet, aber der Abschlussstatus bleibt offen

Damit können Sie später zwischen PTY-Problem, UI-Problem und Modellwartezeit unterscheiden.

Ein Build ist kein reiner Terminaltest. Er kombiniert Prozessstart, Dateizugriffe, kontinuierliche Ausgabe, mögliche Unterprozesse und oft lange Phasen ohne sichtbare Aktivität. Deshalb sollten Sie mindestens drei Ebenen getrennt betrachten.

Erste Ebene: Ausgabe-Fortschritt. Verwenden Sie einen Befehl, der regelmäßig Statuszeilen erzeugt:

for i in $(seq 1 20); do
  printf 'progress=%s\n' "$i"
  sleep 1
done

Sie müssen keine allgemeine Performancezahl daraus ableiten. Entscheidend ist, ob die Ausgabe kontinuierlich ankommt oder erst nach größeren Blöcken sichtbar wird.

Zweite Ebene: Bedienbarkeit. Starten Sie danach einen realistischen Build oder Testlauf. Prüfen Sie, ob Sie während der Ausgabe noch scrollen, Eingaben senden oder die Sitzung sauber verlassen können. Ein Prozess kann weiterarbeiten, während die Oberfläche keine neuen Daten anzeigt. Umgekehrt kann die Oberfläche aktiv aussehen, obwohl der eigentliche Prozess bereits beendet ist.

Dritte Ebene: Abschluss und Abbruch. Verwenden Sie einen kontrollierten Langläufer:

trap 'printf "received-term\n"; exit 143' TERM
while true; do
  printf 'running\n'
  sleep 2
done

Lösen Sie den Abbruch aus und prüfen Sie anschließend:

• Wird der Abbruch an die richtige Sitzung gesendet?
• Erscheint eine Abschlussmeldung?
• Wird ein Exit-Code oder ein Signalstatus angezeigt?
• Existiert der Prozess nach dem Abbruch noch?
• Läuft ein Kindprozess weiter?
• Kann ein neuer Befehl im selben Arbeitsverzeichnis gestartet werden?

Die Node.js-Dokumentation weist darauf hin, dass subprocess.killed nur anzeigt, dass ein Signal erfolgreich gesendet wurde. Es beweist nicht, dass der Prozess bereits beendet ist. Auch ein close- oder exit-Ereignis muss vom tatsächlichen Prozessstatus unterschieden werden. (nodejs.org)

Das ist für DeepSeek Harness auf einem entfernten Mac besonders wichtig. Ein „Abbrechen“-Button kann aus Benutzersicht reagiert haben, während ein Build-Unterprozess noch läuft. Prüfen Sie deshalb den Prozessstatus mit einer separaten Sitzung oder mit einer eindeutig identifizierbaren Prozessabfrage.

Sie müssen nicht jede denkbare Terminalfunktion testen. Wählen Sie nur Programme, die in Ihrem Arbeitsablauf tatsächlich Terminaleingaben benötigen. Geeignet sind zum Beispiel ein Build-Tool mit Rückfragen, ein interaktiver Git-Workflow oder ein Dienst, der auf Terminalgröße und Steuerzeichen reagiert.

Ihre Prüfpunkte sollten begrenzt bleiben:

• Reagiert das Programm auf Eingaben ohne zusätzliche Zeile?
• Bleibt die Cursorposition plausibel?
• Wird eine Größenänderung übernommen?
• Funktionieren Ctrl+C und ein normaler Exit?
• Wird der Prozess nach dem Verlassen tatsächlich beendet?
• Bleibt das Arbeitsverzeichnis unverändert?

Die node-pty-Dokumentation nennt sowohl Schreibzugriffe als auch resize als zentrale Terminaloperationen. (github.com) Daraus folgt eine konkrete Regressionsprüfung: Testen Sie keine lange Liste von Terminal-Features, sondern genau die Eingabe-, Größen- und Exit-Aktionen, die Ihr DeepSeek-Harness-Workflow ausführt.

Wenn der Test scheitert, bewahren Sie eine minimale Reproduktion auf. Dazu gehören:

1. DeepSeek-Harness-Version.
2. macOS-Version und Prozessorarchitektur.
3. Node-Version.
4. verwendete Shell und relevante Umgebungsvariablen.
5. exakter Befehl.
6. erwartete und tatsächliche Ausgabe.
7. Zeitpunkt des Fehlers.
8. Prozessstatus nach dem Fehler.

So vermeiden Sie, dass ein komplexer Agentenlauf die eigentliche Terminalursache verdeckt.

Kann das node-pty-Upgrade Bash-Verzögerungen vollständig beseitigen?

Nein. Der Release nennt zusätzlich eine Korrektur für verzögerte persistente Bash-Aufrufe im Minimalmodus und ein Upgrade auf node-pty 1.2 beta. Diese Hinweise betreffen unterschiedliche Fehlerketten. Prüfen Sie daher Eingabe, Ausgabe, Abschlussstatus und Abbruch separat. Ein schneller Einzelbefehl beweist nicht, dass lange Builds oder dauerhaft laufende Bash-Prozesse stabil funktionieren.

Müssen Sie DeepSeek Harness auf einem entfernten Mac neu konfigurieren?

Eine pauschale Neukonfiguration ist aus dem Release nicht abzuleiten. Prüfen Sie zuerst die tatsächlich installierte Harness-Version, die Node-Laufzeit, die Plattformarchitektur, die Shell-Umgebungsvariablen und die Berechtigungen. Eine Neuinstallation kann bei nativen Abhängigkeiten sinnvoll sein, ersetzt aber keinen Vergleichstest mit identischem Arbeitsverzeichnis und identischen Befehlen.

Welche Befehle sollten Sie nach dem Upgrade auf rc.7 erneut testen?

Beginnen Sie mit einem interaktiven Bash-Befehl, einem Befehl mit kontinuierlicher Ausgabe, einem realistischen Build und einem kontrollierten Abbruch. Ergänzen Sie ein Programm mit echter Terminaleingabe, sofern Ihr Arbeitsablauf dies benötigt. Dokumentieren Sie dabei nicht nur die sichtbare Ausgabe, sondern auch Exit-Code, Prozessstatus, Reconnect-Verhalten und mögliche Seiteneffekte im Arbeitsverzeichnis.

Beeinflusst eine unterbrochene Remote-Mac-Verbindung den laufenden Prozess?

Das lässt sich nicht allein aus dem geschlossenen Browserfenster beantworten. Die Benutzeroberfläche, die PTY-Sitzung und der gestartete Unterprozess können unterschiedliche Zustände haben. Nach einer absichtlichen Trennung müssen Sie deshalb prüfen, ob weiterhin Ausgabe entsteht, ob der Prozess noch existiert, ob eine Wiederaufnahme möglich ist und ob ein erneuter Abbruch tatsächlich den richtigen Prozess beendet.

Ein Verbindungsabbruch darf nicht nur als UI-Problem behandelt werden. Schließen Sie den Browser-Tab, unterbrechen Sie die Netzwerkverbindung oder trennen Sie die Remote-Sitzung während eines kontrollierten Langläufers. Öffnen Sie danach eine neue Verbindung und erfassen Sie vier Zustände:

• Ist die alte Ausgabe wieder sichtbar?
• Können Sie in derselben Sitzung weiterarbeiten?
• Ist der Prozess noch aktiv?
• Können Sie ihn beenden, ohne einen neuen Prozess zu treffen?

Ein Reconnect kann die Anzeige wiederherstellen, ohne den alten Prozess kontrollierbar zu machen. Umgekehrt kann ein Prozess weiterlaufen, obwohl keine Ausgabe mehr in der Oberfläche erscheint. Planen Sie für kritische Jobs deshalb weiterhin eine eigene Hintergrundaufgaben-Strategie. Der Prozessstatus darf nicht allein aus dem Zustand des Browsers abgeleitet werden.

Für die betriebliche Abnahme können Sie die Ergebnisse mit einer Prüfung von Hintergrundaufgaben in DeepSeek Harness verbinden. Wenn ein Job nach einem Reconnect weiterlaufen muss, benötigen Sie eine dokumentierte Zustandsprüfung und nicht nur einen sichtbaren Terminalverlauf.

Führen Sie parallel nur wenige repräsentative Aufgaben aus, die Ihren Alltag abbilden. Eine Sitzung schreibt laufende Statuszeilen. Eine zweite wartet auf Eingabe. Eine dritte führt einen kurzen Build oder Test aus. Der Zweck ist nicht, eine allgemeine maximale Parallelität zu bestimmen. Solche Grenzwerte wären ohne Ihre echte Konfiguration und eine reproduzierbare Messreihe nicht belastbar.

Achten Sie stattdessen auf Isolation:

• Vermischen sich Ausgaben verschiedener Sitzungen?
• Beendet ein Abbruch die falsche Aufgabe?
• Bleibt das Arbeitsverzeichnis jeder Sitzung korrekt?
• Werden Umgebungsvariablen zwischen Sitzungen geteilt?
• Bleibt die Oberfläche bedienbar, wenn eine andere Aufgabe viel Ausgabe erzeugt?
• Entstehen nach einem Reconnect doppelte oder fehlende Ausgaben?

Die Upstream-Dokumentation weist außerdem darauf hin, dass node-pty nicht thread-safe ist und Prozesse mit den Berechtigungen des übergeordneten Prozesses starten. (github.com) Für Ihre Mac-Prüfung folgt daraus keine pauschale Fehlermeldung, aber ein klarer Kontrollpunkt: Prüfen Sie Benutzerrechte, Arbeitsverzeichnis und Prozesszuordnung explizit. Besonders bei einem über das Netzwerk erreichbaren Dienst müssen Sie die Rechte des Parent-Prozesses und die DSGVO-relevante Verarbeitung von Quelltext, Logs und Zugangsdaten berücksichtigen.

1. Versionen einfrieren. Erfassen Sie die bisherige DeepSeek-Harness-Version, rc.7, Node-Version, macOS-Version, Architektur und Shell.
2. Testarbeitsbereich klonen. Nutzen Sie ein reproduzierbares Verzeichnis ohne produktive Zugangsdaten. Prüfen Sie vorher Git-Status und Dateirechte.
3. Basistest mit der alten Version ausführen. Speichern Sie Eingabe, Ausgabe, Exit-Status, Abbruchverhalten und Prozessstatus.
4. Auf rc.7 aktualisieren. Installieren Sie die Version kontrolliert. Prüfen Sie, ob die native node-pty-Abhängigkeit tatsächlich aus dem erwarteten Paketbestand geladen wird.
5. Dieselben Tests wiederholen. Verwenden Sie identische Befehle, identische Arbeitsverzeichnisse und möglichst dasselbe Netzwerkprofil.
6. Reconnect absichtlich auslösen. Trennen Sie die Verbindung während Ausgabe und während eines laufenden Builds.
7. Entscheidung dokumentieren. Bewerten Sie jeden Test als bestanden, eingeschränkt oder fehlgeschlagen. Ein einzelner Erfolg reicht nicht für eine vollständige Freigabe.

Die Installations- und Laufzeitvoraussetzungen sollten Sie zusätzlich mit der offiziellen DeepSeek-Harness-Projektbeschreibung und dem Release von v0.1.0-rc.7 abgleichen. Das Repository weist ausdrücklich darauf hin, dass sich die Kompatibilität während der Developer Preview ändern kann. (github.com)

Die folgenden Tabellen sind kein Ersatz für Messwerte. Sie helfen Ihnen, die Entscheidung nach Fehlerklasse zu treffen.

Erstellen Sie für jeden Test einen kurzen Datensatz:

• Prüfdatum und Zeitzone
• Harness-Version
• node-pty-Version, sofern sichtbar
• macOS-Version
• Node-Version
• Mac-Architektur
• Befehl und Arbeitsverzeichnis
• erwarteter Abschluss
• tatsächlicher Abschluss
• Prozessstatus nach Abbruch
• Verhalten nach Reconnect
• Umgang mit Logs und sensiblen Daten

Für die Remote-Bereitstellung sollten Sie diese Punkte in Ihre interne Abnahme- und Übergabedokumentation übernehmen. Wenn Sie für den Vergleich eine getrennte Mac-Umgebung benötigen, können Sie die verfügbaren Mac-Umgebungen anhand Ihrer Testanforderungen prüfen. Eine Übersicht der möglichen Remote-Arbeitsumgebungen finden Sie außerdem auf der deutschen CALMVPS-Übersichtsseite. Der technische Vorteil einer gemieteten Umgebung liegt dabei nicht automatisch in einer schnelleren Shell. Entscheidend ist, ob Sie eine reproduzierbare Umgebung mit dokumentierter Übergabe, klaren Zugangsdaten, begrenzten Berechtigungen und nachvollziehbarem Rückbau erhalten.

Erfahrungshinweis: Wenn der Fehler nur nach einem Reconnect auftritt, markieren Sie ihn nicht vorschnell als node-pty-Regression. Erst der Vergleich zwischen laufendem Prozess, PTY-Sitzung und Web-Oberfläche zeigt, welche Schicht betroffen ist.

Wenn Sie derzeit auf einem gemeinsam genutzten lokalen Mac testen, entstehen häufig drei reale Nachteile: Die Node- und Paketstände ändern sich nebenbei, laufende Prozesse konkurrieren um dieselbe Arbeitsumgebung, und ein Netzwerkabbruch lässt sich schwer reproduzieren. Bei einem selbst verwalteten Gerät kommen außerdem Wartung, Zugriffsschutz, Backups und die saubere Trennung von Test- und Produktivdaten hinzu.

Eine gemietete Mac-Umgebung von CALMVPS ist für diesen konkreten Fall dann interessanter, wenn Sie nur vorübergehend einen kontrollierten Testknoten, eine zweite Referenzumgebung oder eine isolierte rc.7-Prüfung benötigen. Sie vermeiden damit nicht automatisch alle Terminalfehler. Sie erhalten aber eine klarer abgrenzbare Umgebung, in der Sie Version, Arbeitsverzeichnis, Zugriffsmodell und Rückbau dokumentieren können. Für dauerhafte Hochlast, spezielle physische Schnittstellen oder eine langfristig unveränderte Produktionsumgebung kann ein eigener Mac weiterhin die bessere Wahl sein.

Führen Sie deshalb zuerst die kleine Rückkehrprüfung durch. Wenn Bash, Langläufer, Abbruch und Reconnect sauber getrennt bewertet sind, können Sie entscheiden, ob rc.7 nur für einen beaufsichtigten Pilot, für bestimmte Remote-Mac-Aufgaben oder bereits für einen größeren Testbereich freigegeben wird.