Das bereits angemeldete Safari lokal automatisieren (nur macOS)

Für wen

Wenn ein Assistent in dem Safari, das du schon offen und angemeldet hast, zuerst die Seite klar sehen und dann per Referenz klicken oder ausfüllen soll, passt dieser Weg. Er steuert das stabile Safari, das mit macOS kommt, nicht einen extra gestarteten, sauberen Isolationsbrowser. Harte Voraussetzung: die Maschine muss macOS sein, und Node.js 20+ muss hier schon installiert sein. Für Windows oder Linux gibt es in den vorhandenen Docs keine nutzbaren Schritte.

Das Repository stellt sich auf die Linie „die bereits angemeldeten Gmail-, GitHub-, Ahrefs-, Slack- und Online-Banking-Sitzungen weiter nutzen“ und erwähnt natives WebKit sowie Hintergrundbetrieb. Der Assistent trifft also einen echten Loginzustand, keine leere Demositzung. Wer aufruft, gilt als berechtigt, zu sehen, was auf diesen Tabs schon steht.

Es passt nicht zu Leuten, die nur in einer Isolation tippen wollen oder dem Assistenten keine echten Konten zeigen wollen. Nicht-Apple-Systeme haben auch keinen zweiten Installationsweg. Ist das Ziel eine „frische, abgemeldete, wegwerfbare Sitzung“, beschreiben die vorhandenen Docs diesen Weg nicht.

Erster Versuch in 3 Minuten

Der offizielle Hauptweg ist nur einer: auf einem Mac, der die Voraussetzungen erfüllt,

npx safari-mcp

Das Repository sagt, eine globale Installation sei zuerst nicht nötig. Die optionale Dauerinstallation ist npm install -g safari-mcp; beim ersten Versuch nicht diesen Weg nehmen.

Vor dem Start diese vier Punkte prüfen: das System ist ein beliebiges macOS mit Safari; Node.js ist 20 oder neuer; in Safari ist Settings → Advanced → Show features for web developers an; dann Develop → Allow JavaScript from Apple Events an. Fehlt eines, haben spätere Aufrufe keine Grundlage.

Der Konfigurationsort ist genau dieser Startbefehl. Ihn dem MCP-Host übergeben, damit er den Dienst startet. Die vorhandenen Docs nennen keine JSON-Feldnamen eines konkreten Clients; hier kein Konfigurationsmuster ergänzen und keine Extra-Startflags erfinden.

Beim ersten Mal nur beobachten: safari_snapshot aufrufen und den accessibility tree der aktuellen Seite lesen. Erfolgssignal ist zurückgegebener Seitenstatus, kein Fehler und kein leerer Baum. Dieser Lesevorgang sieht die echte Seitenstruktur, die du ansiehst, inklusive sichtbarer Steuerelemente auf angemeldeten Sites. Das ist kein Nullrisiko und nicht als „keine lokalen Lesezugriffe, kein Netz“ zu lesen.

Wenn mehrere Assistenten auf derselben Maschine Safari zugleich nutzen, ist die geteilte Form in den Docs:

SAFARI_MCP_HTTP=1 SAFARI_MCP_HTTP_PORT=9225 npx safari-mcp

Ein alleiniger erster Versuch braucht das nicht.

Anwendungsfälle

Fall 1: Den aktuellen Tab sehen, dann den nächsten Schritt entscheiden. Auf der schon offenen Safari-Seite safari_snapshot aufrufen und accessibility tree plus Seitenstatus holen. Die Docs listen das als ersten Schritt des empfohlenen Workflows, Ziel Get page state. Es passt zur Prüfung, auf welcher Seite du stehst und welche Steuerelemente referenzierbar sind. Die vollständige Feldstruktur ist nicht entfaltet; bestätigt ist nur, dass Seitenstatus und accessibility tree kommen. Diesen Schritt nicht als Navigation oder Seitenänderung lesen; die vorhandenen Docs geben keine Navigationsbefehle.

Fall 2: Einmal per Referenz interagieren und zurücklesen. Schritt zwei ist safari_click/fill/..., Klick oder Ausfüllen per ref; Schritt drei läuft safari_snapshot erneut zur Kontrolle. Das verlangt ein ref aus Fall 1; keine Koordinaten aus der Luft klicken. Klicks und Ausfüllen ändern die Seite und haben Nebenwirkungen; vor dem Handeln einen Bestätigungspunkt setzen — ob im zweiten Snapshot das passende Steuerelement oder der Text wie erwartet geändert hat. Der Werkzeugname steht als safari_click/fill/...; weitere Interaktionsnamen fehlen einzeln, also keine undokumentierten Befehle ergänzen.

Nutzungsgrenzen

Nur macOS. Node.js 20+ ist Pflicht, Safari-Entwicklerfunktionen und JavaScript from Apple Events müssen an sein. Der Dienst öffnet das stabile Safari, in das du schon eingeloggt bist; Mail, Codehosting, Analysebackends, Chat und Banking-Sitzungen können in die Sicht des Assistenten geraten. Keine Netzisolation und keine lokale Nur-Lese-Sandbox annehmen.

Bei Gleichzeitigkeit den Daemon mit SAFARI_MCP_HTTP=1 teilen; die Docs sagen außerdem, dass bei fehlgeschlagener Tabverfolgung geschlossen wird, statt den aktiven Tab zu treffen, den du nutzt. Fehlercodes, Rückgängig-Schritte und Werkzeugparameter jenseits von safari_snapshot und safari_click/fill stehen nicht in den vorhandenen Docs. Hintergrundbetrieb und niedrigere CPU sind Vergleichsbehauptungen des Repos, keine Garantie für diese Maschine. Ist der erste Versuch nur ein Snapshot, liest er trotzdem eine echte Seite; zuerst Banking-Tabs oder Tabs meiden, die du nicht offenlegen willst.