Claude Code im Browser: zeigen statt beschreiben

Zwei Chrome-Erweiterungen verbinden Claude Code mit Ihrem Browser. Claude in Chrome gibt dem Agenten Zugriff auf die Seite, die Sie gerade vor sich haben. Mit Vibe Annotations klicken Sie das kaputte Element einfach an, statt es zu beschreiben.
Es folgen die Installation beider Erweiterungen, der Ablauf, den wir auf dieser Website täglich fahren, und die zwei Stellen, an denen uns das Setup ausgebremst hat.
Teil 1: Claude Code die Seite sehen lassen
Claude in Chrome reicht Claude Code das DOM durch, dazu die Konsole, die Netzwerkaufrufe und die Möglichkeit zu klicken. Der Agent kann damit selbst nachsehen, ob sein CSS greift.
Vier Dinge müssen zusammenkommen:
- Ein direkter Anthropic-Tarif: Pro, Max, Team oder Enterprise. Über Amazon Bedrock, Google Cloud oder Microsoft Foundry gibt es die Funktion nicht.
- Chrome oder Edge. Brave, Arc, Vivaldi und Opera werden ebenfalls erkannt. WSL wird nicht unterstützt.
- Die Erweiterung Claude in Chrome, Version 1.0.36 oder neuer.
- Eine Sitzung, in der Sie angemeldet sind.
Dann:
- Erweiterung aus dem Chrome Web Store installieren.
- Mit
claude --chromestarten. Beim ersten Start erscheint ein einmaliger Berechtigungsdialog. Erteilen Sie dort die Chrome-Berechtigung. Fehlt sie, werden die Browser-Tools nie geladen. /chromeausführen. Dort muss „Status: Enabled” und „Extension: Installed” stehen.
Falle eins: Ein API-Key setzt das Flag lautlos außer Kraft. Die Erweiterung kann sich weder mit einem API-Key noch mit einem langlebigen Token aus claude setup-token anmelden, also bewirkt --chrome nichts und meldet auch nichts. Melden Sie sich stattdessen mit /login an.
Falle zwei: Nach einer frischen Installation muss Chrome neu starten. Claude Code legt beim ersten Aufruf eine Konfiguration für den Native-Messaging-Host an, und Chrome liest diese Datei nur beim Start.
Das Panel hinter /chrome bietet außerdem „Enabled by default”. Wir lassen die Option aus, sonst laden die Browser-Tools in jede Sitzung, auch in die, die nie eine Seite öffnet.
Teil 2: auf das Element zeigen, statt es zu beschreiben
Vibe Annotations besteht aus einer Chrome-Erweiterung und einem lokalen Server, MIT-lizenziert und kostenlos. Sie klicken in Ihrer laufenden App ein Element an und schreiben dazu, was daran nicht stimmt.

Genau diese Annotation hat den Screenshot angefordert.
Sie trägt die DOM-Auswahl mit, dazu die Komponente dahinter, den Viewport, einen Ausschnitts-Screenshot und Ihre Anweisung. Claude Code liest das alles über MCP. Ihren Rechner verlässt nichts, die Annotationen liegen in ~/.vibe-annotations/annotations.json.
- Erweiterung Vibe Annotations aus dem Chrome Web Store installieren.
npx vibe-annotations-server initausführen. Der Befehl installiert den Server, startet ihn auf Port 3846 und trägt den MCP-Server im User-Scope bei Claude Code ein.- In einer Sitzung
/mcpaufrufen.vibe-annotationsmuss in der Liste stehen.
Bleiben Sie beim voreingestellten User-Scope. init --project schreibt den Eintrag stattdessen in die .mcp.json des Projekts. Der Endpunkt lautet 127.0.0.1, im Repository wird daraus tote Konfiguration: für alle im Team, die den Server nicht laufen haben, und für die CI, die gar keinen Browser besitzt.
Der tägliche Ablauf
- Dev-Server starten und die App auf localhost öffnen.
- In der Leiste der Erweiterung auf Annotate klicken.
- Ein Element anklicken und hinschreiben, was nicht stimmt. So oft wiederholen wie Sie wollen, über beliebig viele Seiten.
- In Claude Code sagen: read and implement my vibe annotations.
Das Bündeln ist der eigentliche Gewinn. Gehen Sie den ganzen Ablauf einmal durch und setzen Sie unterwegs Ihre Annotationen, dann übergeben Sie eine einzige Warteschlange. Claude Code holt sich jede Annotation samt Element und fragt nie nach, welchen Button Sie gemeint haben.
Ganz ohne Übergabe geht es mit start watching vibe annotations. Claude Code hält die Verbindung offen und nimmt neue Annotationen auf, sobald Sie sie anlegen.
Oder Sie tippen /loop process vibe annotations. Der eingebaute Loop-Befehl wiederholt diesen Prompt in eigenem Takt, sodass neue Annotationen einfließen, während Sie weiter annotieren. So haben wir diesen Beitrag überarbeitet.
Wo es hakt
| Symptom | Behebung |
|---|---|
| Der Browser verbindet sich nicht | Chrome neu starten, dann /chrome und Reconnect extension wählen |
| Die Tools reagieren nach einer Pause nicht mehr | Der Service Worker ist eingeschlafen. /chrome, Reconnect extension |
| Claude sieht keine Annotationen | vibe-annotations-server status ausführen. Der Server ist ein eigener Prozess und kann sich selbst beenden |
| Es öffnet sich der falsche Browser | /chrome, dann Select browser |
--chrome scheint wirkungslos | Sie hängen an einem API-Key oder einem Setup-Token. Mit /login anmelden |
Serverbefehle: vibe-annotations-server status, stop, restart.
Drei Grenzen, bevor Sie einen Workflow darauf aufbauen:
- Annotationen sind ein Werkzeug für localhost, kein Bugtracker für die Produktion.
- Beide Teile laufen lokal und interaktiv, in einer headless CI gibt es sie also nicht. Unser Gitea-Agent prüft ausschließlich mit
npm run build. - Screenshots und aufgezeichnete GIFs halten alles fest, was auf dem Bildschirm steht, angemeldete Konten inklusive.
Was sich tatsächlich geändert hat
Besser in CSS wird das Modell durch keine der beiden Erweiterungen. Sie streichen den Übersetzungsschritt zwischen dem, was Sie sehen, und dem, was Sie in Worte fassen müssen.
Aus hinsehen, beschreiben, warten, nachbessern wird hinsehen, klicken, übergeben. Der Agent muss nicht mehr raten, welchen Button Sie meinten, denn Sie haben es ihm mit dem Klick schon gesagt.
Seit wir nicht mehr beschreiben, brauchen wir für einen kleinen UI-Fix statt drei bis vier Durchläufen etwa einen. Unsere eigene Beobachtung an einer Codebasis, kein Benchmark.
Wenn ein schneller Build Ihr Frontend bis hierher gebracht hat und es jetzt jemanden braucht, der es tragfähig macht: genau das ist unsere Arbeit. Nehmen Sie Kontakt auf.

