Zwei Prüfungen entscheiden über die erste Freigabe: Der Hook muss wiederholbar auslösen, und ein Fehler darf nicht stillschweigend zur Werkzeugfreigabe führen. Für die erste Version wird deshalb genau ein beobachtbarer Sperrpunkt eingerichtet. Erst nach dem Test von Erlaubnis, Ablehnung, Ausnahme und Timeout kommen weitere Regeln hinzu.
Diese Anleitung richtet sich an Agent-Entwickler, die Werkzeugaufrufe kontrollieren möchten, an Plattform-Teams mit projekt- und umgebungsweiten Regeln sowie an Betreiber eines Remote-Mac, die Hooks auch nach Reboot und Sitzungsabbruch nachvollziehbar ausführen müssen.
[ SECTION_01 ] Der belastbare Startpunkt ist kleiner als eine vollständige Hook-Sammlung
DeepSeek Harness befindet sich laut offiziellem Repository weiterhin in der Developer Preview. Dort wird ausdrücklich vor inkompatiblen Änderungen gewarnt. Für eine Anleitung zur DeepSeek Harness Hooks Konfiguration bedeutet das: Ein Beispiel aus einem anderen Agent-Produkt ist kein belastbarer Konfigurationsbeleg. Pfad, Ereignisname, Matcher und Ausgabevertrag müssen für den verwendeten Quellstand geprüft werden. (github.com)
Ein Hook kann einen Kontrollpunkt in der Agent-Ausführung bilden. Er kann beispielsweise:
- einen Werkzeugaufruf vor der Ausführung prüfen,
- ein Ergebnis protokollieren,
- eine Stop-Bedingung bewerten,
- zusätzlichen Kontext für einen Lauf bereitstellen.
Er ist jedoch keine Betriebssystem-Sandbox. Ein Hook ersetzt weder Dateirechte noch Prozessisolation, Netzwerkregeln, Geheimnisverwaltung oder eine getrennte Arbeitsumgebung. Wer nur eine Textregel im Agenten hinterlegt, verhindert nicht automatisch, dass ein anderes Programm auf dem Host Dateien liest oder Prozesse startet.
Für den ersten Durchlauf muss daher ein einziges Ziel festgelegt werden:
- Berechtigungsprüfung: Darf ein bestimmter Werkzeugtyp ausgeführt werden?
- Ergebnisprotokollierung: Welche Eingabe und welches Ergebnis müssen nachvollziehbar bleiben?
- Stop-Gate: Unter welcher Bedingung darf der Agent weiterlaufen oder beenden?
- Kontextanreicherung: Welche Laufzeitinformationen werden vor einem Aufruf ergänzt?
Die erste Hook-Version sollte nur eine dieser Aufgaben erfüllen. Werden Sperre, Audit und Kontextaufbau gleichzeitig eingebaut, lässt sich ein Fehler später kaum einer Ursache zuordnen.
[ SECTION_02 ] Vor der Konfiguration steht die Quellenprüfung
Die offizielle Projektstruktur enthält getrennte Dokumentationsbereiche für Lebenszyklus, Konfiguration, Werkzeugkatalog und Tool-Ausführung. Diese Bereiche sind vor jeder Konfiguration zu prüfen, weil sie unterschiedliche Fragen beantworten: Wo wird eine Einstellung geladen? Wann wird ein Ereignis erzeugt? Welche Werkzeuge passieren die Ausführungspipeline? (github.com)
Für die Prüfung genügt folgende Reihenfolge:
- den verwendeten Release-Tag oder Commit festhalten,
- die aktuelle Konfigurationsübersicht öffnen,
- die Ereignis- und Lebenszyklusdefinition prüfen,
- die Tool-Ausführungspipeline lesen,
- die Release-Notizen auf Änderungen an Hooks, Matchern und Rückgabewerten kontrollieren.
Am 17.08.2026 war im offiziellen Repository der Tag dsh-v0.1.0-rc.7 sichtbar. Diese Datumsangabe ist keine Empfehlung, genau diesen Stand zu verwenden. Sie zeigt vielmehr, warum ein Versionsvermerk in jedem Testprotokoll erforderlich ist. (github.com)
Eine Konfigurationsdatei darf erst als belastbar gelten, wenn drei Dinge zusammenpassen:
- der Pfad wird vom aktuellen Startvorgang tatsächlich geladen,
- der Ereignisname ist in der aktuellen Quelle definiert,
- das Ausgabeformat wird von der Laufzeit ausgewertet.
Fehlt einer dieser Nachweise, sollte kein konkreter Schlüssel wie decision, allow, deny oder timeout als offiziell behandelt werden. Solche Namen sind in verschiedenen Agent-Systemen verbreitet, aber daraus folgt keine Gültigkeit für DeepSeek Harness.
[ SECTION_03 ] Der erste Vergleich: minimaler Hook gegen vollständige Automatisierung
| Ansatz | Beobachtbarkeit | Fehlerrisiko | Berechtigungsumfang | Bewertung für den Start |
|---|---|---|---|---|
| Ein Hook, ein Matcher, ein Protokoll | hoch | niedrig | eng | 9/10 |
| Hook für mehrere Werkzeugfamilien | mittel | mittel | breiter | 6/10 |
| Vollständige Skriptsammlung mit Stop- und Auditlogik | niedrig | hoch | sehr breit | 3/10 |
| Hook plus Betriebssystem-Sandbox | hoch | niedriger | technisch begrenzt | 10/10 |
Die Tabelle ist kein Leistungsbenchmark. Sie bewertet die Abnahmefähigkeit. Ein kleiner Hook erzeugt wenige mögliche Fehlerpfade. Eine Sammlung aus PreToolUse, Ergebnisprüfung, Stop-Gate und Kontextinjektion kann zwar mehr abdecken, aber sie erschwert die Frage, ob eine Ablehnung aus dem Matcher, dem Skript, der Laufzeit oder dem Host stammt.
Für die erste Regel eignet sich ein risikoarmer Werkzeugaufruf. Der Hook soll zunächst nur feststellen, dass er ausgelöst wurde, die Eingabe strukturiert protokolliert und eine dokumentierte Entscheidung zurückgibt. Zerstörerische Befehle, echte Zugangsdaten und produktive Arbeitsverzeichnisse gehören nicht in diesen Test.
[ SECTION_04 ] Erster Durchlauf: eine Regel reproduzierbar auslösen
Schritt 1: Arbeitsbereich und Rückfallversion sichern
Legen Sie einen isolierten Testarbeitsbereich an. Sichern Sie die Ausgangskonfiguration als unveränderte Rückfallversion. Notieren Sie:
- verwendeten Release-Tag oder Commit,
- Startmethode,
- Arbeitsverzeichnis,
- verwendeten Interpreter,
- relevante Umgebungsvariablen ohne deren geheime Werte,
- erwarteten Werkzeugnamen.
Die offizielle Startdokumentation nennt für den Web-Betrieb Node.js sowie einen lokalen Standard-Endpunkt unter 127.0.0.1:3080. Diese Angaben beschreiben den Startweg, nicht die Existenz eines Hook-Schemas. (github.com)
Schritt 2: Nur einen Matcher auswählen
Wählen Sie einen einzelnen Werkzeugtyp oder eine eindeutig erkennbare Werkzeugklasse. Ein Matcher, der auf jedes Werkzeug passt, ist für den ersten Test ungeeignet. Er kann normale Aufgaben blockieren und verschleiert, ob der Hook tatsächlich auf den erwarteten Aufruf reagiert.
Ein zu enger Matcher hat das gegenteilige Problem: Varianten des Werkzeugnamens, zusätzliche Argumente oder eine andere Aufrufroute können unbemerkt durchlaufen. Deshalb wird zuerst ein exakt definierter Testaufruf verwendet. Erst danach werden Varianten einzeln ergänzt.
Schritt 3: Eingabe und Ergebnis getrennt protokollieren
Das Protokoll muss mindestens unterscheiden zwischen:
- Zeitpunkt des Ereignisses,
- Sitzungs- oder Laufkennung,
- Werkzeugtyp,
- reduzierter Eingabe,
- Matchergebnis,
- Hook-Ausgang,
- Ergebnis der Agent-Laufzeit.
Pfade mit Kundennamen, API-Schlüssel, Session-Tokens und vollständigen Umgebungsvariablen gehören nicht in das Log. Für die spätere DSGVO-Prüfung ist ein kurzer, pseudonymisierter Datensatz besser als ein vollständiger Mitschnitt.
Schritt 4: Einen positiven und einen negativen Testfall ausführen
Der positive Fall muss den Matcher treffen und die erwartete Freigabe erzeugen. Der negative Fall muss den Matcher verfehlen oder eine definierte Ablehnung auslösen. Beide Fälle müssen in einer neuen Sitzung wiederholbar sein.
Ein erfolgreicher Aufruf allein reicht nicht. Es muss auch festgehalten werden, dass ein unbeteiligtes Werkzeug nicht durch die Regel blockiert wurde. Genau dieser zweite Nachweis verhindert, dass eine scheinbar funktionierende Regel den gesamten Agentenbetrieb lahmlegt.
Schritt 5: Sitzungsereignis und Laufzeitreaktion vergleichen
Die Konfigurationsdatei beschreibt nur eine Absicht. Der Nachweis kommt aus dem Sitzungsereignis, dem Laufprotokoll oder einem reproduzierbaren Test. Vergleichen Sie daher:
- Wurde der Hook aufgerufen?
- Welche Eingabe erhielt er?
- Welche Entscheidung erzeugte er?
- Hat DeepSeek Harness den Werkzeugaufruf ausgeführt?
- Wurde ein Ergebnis- oder Fehlerereignis gespeichert?
Wenn Schritt 3 und Schritt 4 nicht eindeutig zusammenpassen, bleibt die Freigabe geschlossen. Eine Vermutung wie „Das Skript hat vermutlich allow zurückgegeben“ ist kein Abnahmenachweis.
[ SECTION_05 ] Die Fehlerstrategie entscheidet über die Sicherheit
Die erste echte Sicherheitsprüfung besteht aus vier getrennten Fällen:
- explizite Freigabe: Der Hook liefert die laut aktuellem Protocol gültige Freigabe.
- explizite Ablehnung: Der Hook liefert die gültige Sperrentscheidung.
- Skriptausnahme: Der Hook beendet sich mit einem Fehler oder kann die Eingabe nicht verarbeiten.
- Timeout: Der Hook antwortet nicht innerhalb der vorgesehenen Laufzeit.
Für jeden Fall wird das tatsächliche Agent-Verhalten notiert. Besonders wichtig ist die Frage, ob ein Fehler den Werkzeugaufruf stoppt, ob der Agent einen Hinweis erhält oder ob der Aufruf ohne Hook-Entscheidung fortgesetzt wird.
Das Ereignis PreToolUse wird in der Praxis häufig für Kontrollen vor einem Werkzeugaufruf verwendet. Der Begriff allein beweist jedoch nicht, welches Ausgabeformat DeepSeek Harness in der verwendeten Version erwartet. Die Regel sollte daher erst nach Abgleich mit dem aktuellen Hook Protocol produktiv eingesetzt werden.
Bleibt die Fehlerbehandlung unklar, ist „geschlossen bleiben“ die vernünftige Rückfallentscheidung. Das bedeutet nicht zwingend, dass die Laufzeit diese Entscheidung automatisch trifft. Es bedeutet: Das Team darf keine zusätzliche Berechtigung vergeben, bevor das Verhalten belegt ist.
[ SECTION_06 ] Erweiterung auf Bash und Dateischreibvorgänge
Erst wenn der einzelne Test stabil ist, werden riskantere Werkzeugklassen ergänzt. Bash, Dateiänderungen und externe Tools benötigen jeweils eine eigene Regel. Jede Erweiterung erhält eine eigene Rückfallversion.
Vor der Freigabe eines Schreib- oder Befehlswerkzeugs sind mindestens diese Grenzen zu definieren:
- erlaubtes Arbeitsverzeichnis,
- verbotene Pfadbereiche,
- zulässige Parameterformen,
- sichtbare Umgebungsvariablen,
- Netzwerkzugriff,
- Umgang mit nicht auflösbaren Pfaden,
- Logumfang und Aufbewahrung.
Ein Matcher für Bash allein ist zu grob. Er sagt noch nicht, ob ein Befehl harmlos oder gefährlich ist. Umgekehrt kann eine Regel, die nur auf eine exakt erwartete Befehlszeichenfolge passt, leicht durch zusätzliche Argumente oder alternative Schreibweisen umgangen werden.
Die sichere Erweiterung erfolgt deshalb in kleinen Stufen:
- Lesen eines bekannten Testartefakts.
- Schreiben in ein isoliertes Testverzeichnis.
- Aufruf eines ungefährlichen externen Werkzeugs.
- Ablehnung eines bewusst markierten Testfalls.
- Prüfung eines nicht interaktiven Laufs.
Bei jeder Stufe muss das Team den erlaubten Bereich enger halten als den tatsächlichen Host-Bereich. Ein Remote-Mac ist nicht automatisch isoliert, nur weil der Agent über eine entfernte Sitzung bedient wird.
[ SECTION_07 ] FAQ: Pfad, Ablehnung und Neustart
Die folgenden Antworten gelten als Betriebsregeln, nicht als Ersatz für die Prüfung des aktuellen Quellstands.
[ SECTION_08 ] Übergabe auf einen Remote-Mac
Beim Wechsel auf ein Remote-Mac-System wird nicht nur eine Datei kopiert. Die Ausführungsverantwortung wird neu aufgebaut. Ein lokaler Hook kann auf einen Shell-Pfad, einen Paketmanager, ein Arbeitsverzeichnis oder eine Umgebungsvariable zugreifen, die im entfernten, nicht interaktiven Prozess nicht existiert.
Prüfen Sie deshalb in dieser Reihenfolge:
Schritt 6: Hook-Skript und Interpreter verifizieren
Der absolute oder vom System auflösbare Pfad muss im Zielsystem vorhanden sein. Das Skript benötigt die richtigen Dateirechte. Der verwendete Interpreter muss auch ohne interaktive Shell erreichbar sein.
Ein manueller Test in einer geöffneten Terminal-Sitzung genügt nicht. Der Agent kann mit einer reduzierten PATH-Variable, einem anderen Home-Verzeichnis oder einem anderen Benutzer laufen.
Schritt 7: Arbeitsverzeichnis und Umgebungsvariablen prüfen
Viele Hooks funktionieren lokal, weil sie relative Pfade verwenden. Nach einer Remote-Bereitstellung zeigt derselbe relative Pfad möglicherweise auf ein anderes Verzeichnis. Prüfen Sie daher den Startordner, symbolische Verknüpfungen und temporäre Dateien.
Geheime Werte werden nicht in das Protokoll geschrieben. Für die Diagnose genügt ein Ergebnis wie „Variable vorhanden“ oder „Variable fehlt“. Der konkrete Inhalt bleibt verborgen.
Schritt 8: Neustart und Sitzungsabbruch simulieren
Beenden Sie die laufende Sitzung kontrolliert. Starten Sie DeepSeek Harness erneut. Prüfen Sie danach den positiven und den negativen Testfall noch einmal. Wiederholen Sie den Test zusätzlich nach einem Neustart des Remote-Mac.
Der Nachweis muss zeigen, dass der Hook erneut geladen wird, nicht nur, dass ein altes Prozessfenster weiterarbeitet. Eine gespeicherte Konfiguration ohne aktiven Ladebeleg ist kein gültiger Betriebsnachweis.
Schritt 9: Nicht interaktive Ausführung testen
Starten Sie den Ablauf ohne Eingabeaufforderung. Ein Hook, der auf eine Bestätigung per Terminal wartet, kann einen Agentenlauf scheinbar einfrieren. Bei einem Timeout muss klar sein, ob der Aufruf gestoppt, zurückgestellt oder unerwartet fortgesetzt wird.
Für unbeaufsichtigte Aufgaben wird eine unklare Antwort als Fehler behandelt. Der Betrieb bleibt dann geschlossen, bis Ursache und Rückfallversion bekannt sind.
[ SECTION_09 ] End-to-End-Abnahme vor der Freigabe
Vor einer dauerhaften Nutzung werden vier Beleggruppen erstellt:
- Erlaubter Auftrag: Der erwartete Werkzeugaufruf wird ausgeführt.
- Abgelehnter Auftrag: Der definierte Sperrfall wird nicht ausgeführt.
- Fehlerhafter Hook: Ausnahme oder ungültige Ausgabe erzeugt eine nachvollziehbare Reaktion.
- Wiederherstellung: Nach Korrektur oder Rückfallversion funktioniert der erlaubte Auftrag erneut.
Jeder Datensatz erhält Versionsstand, Arbeitsbereich, Triggerpunkt, gekürzte Eingabe, Ergebnis, Fehlerursache und Rückfallaktion. Sensible Daten werden vor der Ablage entfernt oder pseudonymisiert.
Die offizielle Dokumentation beschreibt DeepSeek Harness als Plugin-basierte Architektur und weist auf schnelle Änderungen hin. Das erhöht den Wert eines versionierten Abnahmeprotokolls: Bei einem Upgrade kann das Team gezielt prüfen, ob Hook-Punkt, Konfigurationspfad oder Fehlerreaktion verändert wurden, statt die gesamte Umgebung neu zu erraten. (github.com)
Eine produktive Freigabe ist gerechtfertigt, wenn:
- jeder Testfall wiederholbar ist,
- der negative Fall tatsächlich blockiert,
- ein Hook-Fehler nicht stillschweigend freigibt,
- der Remote-Mac nach Neustart denselben Nachweis liefert,
- Logs keine Geheimnisse oder unnötigen Kundenpfade enthalten,
- eine bekannte Rückfallversion bereitsteht.
Wer nur den positiven Fall testet, prüft die Automatisierung, aber nicht die Kontrolle. Für Agenten mit Schreib- oder Shell-Rechten ist das zu wenig.
[ SECTION_10 ] Bewertung der Einsatzentscheidung
Für einen lokalen Entwicklungsarbeitsplatz ist die Hook-Einführung geeignet, wenn der Betreiber die aktuelle Quelle regelmäßig prüft und die Testfälle selbst ausführen kann. Für CI/CD- oder unbeaufsichtigte Agentenläufe ist eine zusätzliche Betriebssystem- und Netzwerkisolation erforderlich. Für produktive Kundendaten sollte ein Hook niemals die einzige Schutzschicht sein.
Ein eigener Mac bietet maximale Kontrolle über Dateien, Prozesse und lokale Abhängigkeiten. Er verursacht aber langfristige Fixkosten, Wartungsaufwand, Stromverbrauch und eine höhere Verantwortung für Reboots, Updates und Fernzugriff. Ein eigener Rechner ist daher sinnvoll, wenn die Umgebung dauerhaft benötigt wird und physische Schnittstellen oder konstante lokale Datenhaltung wichtig sind.
Ein Remote-Mac ist flexibler für Pilotläufe und zeitlich begrenzte Tests. Die Schwachstellen liegen dort in der Übergabe: Abhängigkeiten können fehlen, Sitzungen können abbrechen, Logs können an der falschen Stelle landen und Neustarts können einen Hook deaktivieren. Wer diese Punkte nicht mit einem Liefer- und Abnahmeprotokoll prüft, tauscht lokale Unbequemlichkeit gegen entfernte Unklarheit.
Für die zeitweise Erprobung einer Hook-Konfiguration kann NOVAKVM deshalb die passendere Option sein, sofern der Ablauf nicht auf dauerhaftem Hochlastbetrieb oder physischen Geräten am Standort beruht. Nach den vier lokalen Testgruppen sollte der Betreiber die Remote-Mac-Bereitstellung, den tatsächlichen Arbeitsbereich und die Wiederherstellung nach Neustart abgleichen. Für eine konkrete Mac-Umgebung kann außerdem die Mac-mini-Bestellung als Vergleich zur dauerhaften Eigenanschaffung dienen. Entscheidend bleibt: Erst wenn Skriptabhängigkeiten, Reboot-Verhalten und Protokollaufbewahrung belegt sind, sollte ein laufender Agent auf dem Remote-Mac weitere Werkzeugrechte erhalten.