ChatGPT und Claude im Browser mit dem eigenen Rechner verbinden
Wer einen lokalen MCP-Server betreibt, verliert die Tools schnell aus den Augen, sobald ChatGPT im Browser oder Claude auf dem Smartphone genutzt wird. Ein Ansatz zeigt, wie sich die Verbindung zum eigenen Computer herstellen lässt, ohne einen Port zu öffnen.
Veröffentlicht am 23. Oktober • Zuerst erschienen auf netbka.hashnode.dev
Du hast einen lokalen MCP-Server zum Laufen gebracht. Claude Desktop sieht ihn, dein Editor sieht ihn, und das Modell führt deinen Build aus, ohne dass du irgendwas einfügen musst. Dann öffnest du ChatGPT in einem Browser-Tab, oder Claude auf dem Handy auf dem Heimweg, und die Tools sind weg. Der Chat ist da, der Rechner ist da, und die beiden kommen einfach nicht zusammen.
Jemand auf r/mcp hat es in einen Satz gepackt: "ChatGPT und Claude im Web können keine lokalen MCP-Server ausführen." Sie können es nicht, und das hat einen einfachen Grund. Hier ist die Erklärung, die beiden Wege daran vorbei und wie du dich entscheidest.
Wenn du in ChatGPT oder Claude im Web einen Connector hinzufügst, spricht dein Browser nicht mit dem MCP-Server. Die Server des Anbieters tun es: Wenn das Modell ein Tool verwenden will, ruft deren Backend die URL auf, die du angegeben hast. Von da an bedeutet localhost deren Maschine, nicht deine, und dein PC sitzt ohnehin meist hinter einem Heimrouter ohne öffentliche Adresse. Die Handy-Apps funktionieren auf dieselbe Weise.
Die Web- und Handy-Apps können daher nur einen MCP-Server unter einer öffentlichen HTTPS-Adresse verwenden. Desktop-Apps können einen lokalen Server als Kindprozess starten und über stdio mit ihm kommunizieren, weshalb derselbe Server an dem einen Ort funktioniert und am anderen nicht.
Das lässt zwei Wege offen, deinem Computer einen erreichbaren Endpunkt zu geben, ohne einen Port an deinem Router weiterzuleiten.
Ein Tunnel-Tool wie cloudflared oder ngrok läuft auf deinem Computer, baut eine ausgehende Verbindung zum Tunnel-Anbieter auf und gibt dir eine öffentliche HTTPS-URL, die an einen lokalen Port weiterleitet. Ich habe selbst so angefangen: ein kleiner Server auf meinem PC, ein Tunnel und ein Login, damit nicht einfach jeder hereinkonnte. Es funktionierte.
Die Risiken kommen mit der URL. In dem Moment, in dem der Tunnel steht, haben deine Tools eine öffentliche Adresse. Ohne Anmeldung kann jeder, der die URL findet, sie aufrufen, und eine schwer zu ratende URL ist kein Passwort: URLs gelangen über Logs, Browserverlauf und Screenshots nach draußen. Führe den Server als normaler Benutzer aus, niemals als Administrator oder root, damit ein böswilliger Aufruf nicht mehr anrichten kann, als dieses Konto kann. Gib nur die Tools frei, die du brauchst. Schließe den Tunnel, wenn du fertig bist, nicht erst Wochen später.
Das andere Muster dreht die Verbindung um. Ein kleiner Agent auf deinem Computer baut eine ausgehende Verbindung zu einem gehosteten MCP-Dienst auf und hält sie offen. Deine KI-App verbindet sich über HTTPS mit diesem Dienst, mit Anmeldung. Wenn das Modell ein Tool aufruft, reicht der Dienst die Anfrage über die offene Verbindung an deinen Computer weiter, der Agent führt sie aus, und das Ergebnis kommt auf demselben Weg zurück. Nichts auf deinem Computer lauscht im Internet, also gibt es keine URL, die auf deine Maschine zeigt und leaked werden könnte.
Der Kompromiss ist Vertrauen: Anfragen und ihre Ausgaben laufen durch den gehosteten Dienst, du verlässt dich also darauf, wer ihn betreibt.
Ich entwickle Local Commander, das auf diese Weise funktioniert, bin also befangen. Der Agent auf jedem Computer öffnet eine ausgehende WebSocket-Verbindung zu localcmd.app und wartet auf Arbeit. Deine KI-App verbindet sich mit der MCP-Adresse von localcmd.app und meldet sich per OAuth an. Von da an kann eine Nachricht, die in Claude auf deinem Handy eingegeben wird, auf dem PC unterm Schreibtisch ausgeführt werden:
Auf dem Heim-PC, führe die Tests in meinem Projektordner aus und sag mir, was fehlgeschlagen ist und warum.
Das Modell liest Dateien, führt Befehle aus, prüft Git oder fragt einen lokalen Webdienst, ob er antwortet, auf dem Computer, den du genannt hast. Wenn mehr als ein Computer online ist und du keinen angegeben hast, weisen die Anweisungen des Servers das Modell an, zu fragen statt zu raten. Es funktioniert aus ChatGPT, Claude, Cursor und anderen Apps, die Remote-MCP mit Anmeldung unterstützen.
Keine Router-Einstellungen, kein Tunnel. Wenn du mehr als einen Computer hast, erreicht derselbe Chat alle davon; darüber habe ich in einem Artikel geschrieben, wie man eine Aufgabe auf allen seinen Computern aus einem einzigen ChatGPT- oder Claude-Chat ausführt.
Zum Relay-Weg und insbesondere zu Local Commander:
Muss ich bei einer der beiden Optionen einen Port an meinem Router öffnen? Nein. Beide wählen sich von deinem Computer aus nach außen. Der Unterschied ist, was am Ende öffentlich wird: Ein Tunnel gibt deinem eigenen Server eine öffentliche URL, während ein Relay deinem Computer keine gibt. Der öffentliche Endpunkt ist der gehostete Dienst, hinter einer Anmeldung.
Funktioniert das auch über die Handy-App? Ja, überall dort, wo die Handy-App den von dir hinzugefügten Connector unterstützt: Sie ruft Tools von der Seite des Anbieters aus auf, genau wie die Web-App. Bei Local Commander muss der Computer dennoch wach, online sein und den Agenten ausführen.
Wenn du vor dieser Hürde gestanden hast, würde ich gerne hören, welchen Weg du genommen hast und wo er dich ausgebremst hat. Die Einrichtungsschritte findest du auch auf der Anleitungsseite. Du kannst Befehle blockieren und einen Computer oder eine KI-App jederzeit auf localcmd.app sperren.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 23 • Originally published at netbka.hashnode.dev
You got a local MCP server working. Claude Desktop sees it, your editor sees it, and the model runs your build without you pasting anything. Then you open ChatGPT in a browser tab, or Claude on your phone on the way home, and the tools are gone. The chat is right there, the computer is right there, and the two never meet.
Someone on r/mcp put it in one line: "ChatGPT and Claude web can't run local MCP servers." They can't, for a plain reason. Here's why, the two ways around it, and how to choose.
When you add a connector in ChatGPT or Claude on the web, your browser doesn't talk to the MCP server. The provider's servers do: when the model wants a tool, their backend calls the URL you gave it. From there, localhost means their machine, not yours, and your PC usually sits behind a home router without a public address anyway. The phone apps work the same way.
So the web and phone apps can only use an MCP server at a public HTTPS address. Desktop apps can start a local server as a child process and talk to it over stdio, which is why the same server works in one place and not the other.
That leaves two ways to give your computer a reachable endpoint without forwarding a port on your router.
A tunnel tool such as cloudflared or ngrok runs on your computer, opens an outgoing connection to the tunnel provider, and gives you a public HTTPS URL that forwards to a local port. I started this way myself: a small server on my PC, a tunnel, and a login so not just anyone could walk in. It worked.
The risks come with the URL. The moment the tunnel is up, your tools have a public address. Without sign-in, anyone who finds the URL can call them, and a hard-to-guess URL isn't a password: URLs leak through logs, browser history and screenshots. Run the server as a normal user, never as administrator or root, so a bad call can't do more than that account can. Expose only the tools you need. Close the tunnel when you're done, not weeks later.
The other pattern turns the connection around. A small agent on your computer opens an outgoing connection to a hosted MCP service and keeps it open. Your AI app connects to that service over HTTPS, with sign-in. When the model calls a tool, the service passes the request down the open connection to your computer, the agent runs it, and the result comes back the same way. Nothing on your computer listens on the internet, so there is no URL pointing at your machine to leak.
The trade-off is trust: requests and their output pass through the hosted service, so you are trusting whoever runs it.
I build Local Commander, which works this way, so I'm biased. The agent on each computer opens an outgoing WebSocket to localcmd.app and waits for work. Your AI app connects to https://localcmd.app/mcp and signs in with OAuth. From then on, a message typed into Claude on your phone can run on the PC under your desk:
On Home PC, run the tests in my project folder and tell me what failed and why.
The model reads files, runs commands, checks Git or asks a local web service whether it answers, on the computer you named. If more than one computer is online and you didn't say which, the server's instructions tell the model to ask instead of guessing. It works from ChatGPT, Claude, Cursor and other apps that support remote MCP with sign-in.
No router settings, no tunnel. If you have more than one computer, the same chat reaches all of them; I wrote about that in How to run one task on all your computers from a single ChatGPT or Claude chat.
For the relay route, and for Local Commander in particular:
Do I need to open a port on my router for either option? No. Both dial out from your computer. The difference is what ends up public: a tunnel gives your own server a public URL, while a relay gives your computer none. The public endpoint is the hosted service, behind sign-in.
Does this work from the phone app? Yes, wherever the phone app supports the connector you added: it calls tools from the provider's side, like the web app. With Local Commander, the computer still has to be awake, online and running the agent.
If you've hit this wall, I'd like to hear which route you took and where it got in your way. The setup steps are also on the guide page: https://localcmd.app/control-multiple-computers-with-ai. You can block commands and revoke a computer or an AI app at localcmd.app at any time.