Chrome-Erweiterung verbindet Google Messages über MCP mit Claude Code

Direkte Integration ohne Docker oder Cloud-Server
Ein Entwickler hat eine Chrome-Erweiterung erstellt, die sich in Google Messages Web-Sitzungen einfügt und diese über das Model Context Protocol (MCP) mit Claude Code verbindet. Die Architektur verwendet stdio-Transport zwischen Claude Code und einem Node.js MCP-Server, der über WebSocket auf localhost:7008 mit der Chrome-Erweiterung kommuniziert.
Was funktioniert vs. bestehende Lösungen
Der Entwickler hat zunächst zwei bestehende Ansätze ausprobiert:
- OpenMessage: Docker-Container, der das libgm-Protokoll mit SSE-Sitzungen verwendet, die nach einigen Minuten Inaktivität ablaufen und zu "Ungültige Sitzungs-ID"-Fehlern führen. Er erfordert einen Neustart des Docker-Containers, um neue Nachrichten zu synchronisieren, und verwendet 7 MCP-Tools (~1.500 Token pro Konversation).
- TextBee: Android-SMS-Gateway-App, die alle privaten SMS-Nachrichten über Cloud-Server leitet (nur SMS, kein RCS). Erfordert einen Webhook-Server plus Tailscale/ngrok-Tunnel, insgesamt fünf bewegliche Teile für einfaches Texten.
Der neue Chrome-Erweiterungsansatz hat drei funktionierende MCP-Tools mit ~300 Token Overhead:
list_chats– Gibt alle Konversationen mit Namen, Ausschnitten und Zeitstempeln zurückread_messages– Bietet vollständigen Nachrichtenverlauf mit Sende-/Empfangsrichtungsend_message– Füllt Text aus, sendet aber nicht tatsächlich (funktioniert derzeit als Entwurfstool)
Das Angular-Isolationsproblem
Google Messages Web ist eine Angular-App, bei der Chrome-Erweiterungs-Inhaltsskripte in einer "isolierten Welt" laufen – einem separaten JavaScript-Kontext von der Seite. Angulars zone.js patcht nur Event-Listener in der Hauptwelt, daher wenn die Erweiterung den Textarea-Wert setzt und auf Senden klickt:
- Der Text erscheint in der Eingabe ✓
- Die Senden-Schaltfläche wird geklickt ✓
- Angulars Formularsteuerung erkennt die Wertänderung nicht, daher denkt der Klick-Handler, dass das Feld leer ist ✗
Versuchte Lösungen
Der Entwickler hat mehrere Ansätze versucht:
- Nativer Wertsetzer + Eingabeereignisse
document.execCommand('insertText')- Vollständige Mausereignissequenz (pointerdown/mousedown/mouseup/click)
- Eingabetaste-Simulation
- Manifest V3
world: "MAIN"Inhaltsskript (kommt am nächsten, sendet aber immer noch nicht)
Debug-Ausgabe vom Hauptwelt-Skript zeigt: {"valueSet": true, "btnLabel": "Send end-to-end encrypted RCS message", "clicked": true, "inputAfter": "text still here...", "sentVia": "none"}
Potenzielle Lösungen zur Erkundung
Der Entwickler erwägt:
chrome.debuggerAPI für vertrauenswürdige Eingabeereignisse- Zugriff auf Angulars NgZone über
__ngContext__auf DOM-Elementen - CDP (Chrome DevTools Protocol) für
Input.dispatchKeyEvent
Das Projekt ist Open Source mit Repository unter https://github.com/GURSEWAKSINGHSANDHU/google-messages-mcp und Issue-Tracking unter https://github.com/GURSEWAKSINGHSANDHU/google-messages-mcp/issues/1.
📖 Den vollständigen Source lesen: r/ClaudeAI
👀 Siehe auch

DebugBase: Eine gemeinsame Wissensdatenbank für Fehler bei KI-Codierungsagenten über MCP
DebugBase ist ein MCP-kompatibles Tool, das eine gemeinsame Wissensdatenbank bereitstellt, in der KI-Coding-Agenten nach bekannten Lösungen für häufige Fehler wie Next.js-Hydratisierungsfehler oder TypeScript-Auflösungsprobleme suchen können. Es enthält 11 MCP-Tools und ist bereits mit 58 Fehler/Lösungs-Paaren aus echten Agenten-Sitzungen vorbelegt.

Browser39: Ein kopfoser Webbrowser für KI-Agenten
Browser39 ist ein Headless-Webbrowser, der speziell für KI-Agenten entwickelt wurde und Webseiten lokal in token-optimiertes Markdown umwandelt, JavaScript ausführt, Cookies und Sitzungen verwaltet, das DOM abfragt und Formulare ausfüllt. Es handelt sich um eine einzelne Binärdatei, die keinen externen Browser, keine Gebühren und keinen externen Dienst benötigt.

Claude Code v2.1.166: Fallback-Modelle, globale Ablehnungsregeln, Sitzungsübergreifende Härtung
Claude Code v2.1.166 führt bis zu 3 Fallback-Modelle ein, glob-Muster in Ablehnungsregeln, gehärtetes sessionsübergreifendes Messaging und Korrekturen für Terminal-Flackern, verwaiste Prozesse und mehr.

Dual DGX Sparks vs. Mac Studio M3 Ultra: Praktischer Vergleich für den lokalen Betrieb von Qwen3.5 397B
Ein Entwickler verglich das lokale Ausführen von Qwen3.5 397B auf einem 10.000 US-Dollar teuren Mac Studio M3 Ultra 512GB und einem 10.000 US-Dollar teuren Dual-DGX-Spark-Setup. Das Mac Studio erreichte 30–40 Tok/s mit 800 GB/s Bandbreite, aber langsamer Vorauffüllung, während die Sparks 27–28 Tok/s mit schnellerer Rechenleistung, aber komplexer Einrichtung lieferten.