Claude Code als Web-Version vorgestellt — Code-Arbeit direkt im Browser delegieren

 (anthropic.com)
11 Punkte von GN⁺ 2025-10-21 | 2 Kommentare | Auf WhatsApp teilen
  • Anthropic hat die Web-Version von Claude Code vorgestellt, mit der Entwickler Code-Arbeit direkt im Browser delegieren können
  • Nach dem Verbinden eines GitHub-Repositorys und der Beschreibung der Aufgabe setzt Claude diese automatisch in einer Cloud-Umgebung um und unterstützt gleichzeitige Mehrfachaufgaben (parallel tasks)
  • Jede Sitzung läuft in einer isolierten Sandbox-Umgebung, um die Sicherheit zu gewährleisten, und bietet automatische PR-Erstellung sowie Änderungszusammenfassungen
  • Diese Beta-Version ist auch in der iOS-App nutzbar, sodass Code auch unterwegs bearbeitet und geprüft werden kann
  • Mit einem sicherheitsorientierten Cloud-Ausführungsmodell werden Entwicklungseffizienz und Sicherheit zugleich gestärkt

Browserbasierte Code-Ausführung

  • Anthropic hat die Funktion Claude Code on the web veröffentlicht
  • Eine Funktion, mit der sich Coding-Aufgaben ohne Terminal allein im Browser direkt an Claude delegieren und ausführen lassen
    • Verbindet man ein GitHub-Repository und beschreibt die Aufgabe, schreibt und bearbeitet Claude den Code automatisch
    • Jede Aufgabe wird einzeln in einer isolierten Cloud-Umgebung ausgeführt, und der Fortschritt lässt sich in Echtzeit verfolgen
    • Nutzer können die Arbeitsrichtung von Claude während der Ausführung auch manuell steuern (steer)

Unterstützung für parallele Aufgaben

  • Claude Code kann Aufgaben über mehrere Repositories hinweg gleichzeitig ausführen (parallel execution)
    • Dadurch lassen sich Bugfixes, Routine-Verbesserungen und parallele Entwicklung kombinieren
    • Nach Abschluss der Arbeit werden automatisch Pull Requests (PRs) erstellt und Änderungszusammenfassungen bereitgestellt, was die Entwicklung beschleunigt
  • Durch cloudbasierte Parallelverarbeitung können Projekte gleichzeitig vorangetrieben werden, ohne lokale Ressourcenbeschränkungen

Für verschiedene Workflows geeignet

  • Die Web-Version ergänzt bestehende Claude-Code-Workflows und eignet sich besonders für folgende Aufgaben
    • Fragen und Antworten zur Projektstruktur oder zum Code-Mapping sowie Code-Erkundung
    • Bugfixes oder die Bearbeitung wiederkehrender und klar definierter Aufgaben
    • Backend-Änderungen und testgetriebene Entwicklung (TDD)
  • Sie ist auch in der iOS-App-Beta verfügbar, sodass sich unterwegs Cloud-Coding-Experimente mit Claude durchführen lassen

Sicherheitsorientierte Ausführung in der Sandbox

  • Alle Aufgaben werden in einer Sandbox-Umgebung mit eingeschränktem Netzwerk- und Dateisystemzugriff ausgeführt
    • Durch Git-Zugriffskontrolle über einen Sicherheits-Proxy können nur autorisierte Repositories erreicht werden
    • Über benutzerdefinierte Netzwerkeinstellungen lassen sich erlaubte Domains (z. B. für npm-Paketdownloads) selektiv hinzufügen
  • Die detaillierte Architektur wird im offiziellen Engineering-Blog und in der Dokumentation vorgestellt

Erste Schritte

  • Claude Code on the web ist derzeit als Research Preview für Pro- und Max-Nutzer verfügbar
    • Unter claude.com/code kann das erste Repository verbunden und die Arbeit gestartet werden
    • Cloud-Sitzungen teilen sich mit bestehendem Claude Code dasselbe Request-Limit (rate limit)
    • Weitere Details finden sich in der offiziellen Dokumentation

Bedeutung

  • Die Web-Version von Claude Code beschleunigt den Cloud-Wechsel des „AI-Agent-Coding“ und präsentiert ein neues Paradigma für Entwicklungsumgebungen, das Entwicklungsgeschwindigkeit, Sicherheit und Mobilität zugleich stärkt

Verwandte Beiträge

2 Kommentare

 
laeyoung 2025-10-21

Ich habe es ausprobiert, und wie erwartet ist es besser, als ich dachte.
 
GN⁺ 2025-10-21
Hacker-News-Kommentare

  • Ich würde gern Erfahrungsberichte dazu hören, worin sich Codex / Claude Code davon unterscheiden, in Cursor per Chat oder Agents zu arbeiten, und was davon besser ist. Ich frage, weil ich in meinem Unternehmen ein effizienter Engineer werden möchte.

  • Unser Team hat bis letztes Jahr so intensiv Claude Code genutzt, dass wir dafür über 70.000 US-Dollar pro Jahr ausgegeben haben, sind inzwischen aber fast vollständig zu Codex CLI gewechselt. Mit Codex CLI konnten wir große Software-Aufgaben bewältigen, die weder für mich persönlich noch für irgendwen in meinem Team zuvor möglich gewesen wären. Jetzt schaue ich mir CC nur noch etwa alle zwei Wochen für Code-Checks und Bug-Dokumentation an, aber die Erfolgsquote ist eher so mittel. Als Claude Code zum ersten Mal erschien, war es wirklich beeindruckend und sofort ein Produkt, das ein Abo wert war. Aber nachdem Codex zu CC aufgeschlossen hatte, ist es bei längeren Aufgaben und schwierigen Problemen deutlich besser. Claude Code hat bei schwierigen Problemen manchmal einfach aufgegeben und vorgeschlagen, lieber ein fertiges Produkt zu kaufen. Dank Codex hat sich die Leistungsfähigkeit unserer gesamten Software-Organisation stark verbessert. Das spricht sich inzwischen langsam herum. Ich stehe in keiner Beziehung zu irgendeiner AI-Firma; persönlich habe ich Anthropic die Daumen gedrückt, aber Codex CLI ist überwältigend besser und dazu günstiger. Wenn Anthropic OpenAI wieder einholen will, braucht es meiner Meinung nach etwas wirklich Innovatives. Aktuell liegt Codex klar vorne.

    • Ich habe auch Codex CLI ausprobiert und es ist wirklich hervorragend. Trotzdem kann ich nicht komplett wechseln, weil Codex einige wichtige Funktionen noch nicht hat, die ich täglich in Claude Code nutze. Zum Beispiel das Berechtigungssystem für Bash-Befehle, Rollbacks innerhalb von Konversation und Code, das einfache Umschalten des Approval-Modus per Keybind, Nachrichten während einer laufenden Aufgabe senden zu können (bei Codex werden sie nach Ende der Aufgabe in die Queue gestellt, bei Claude in Echtzeit eingeschleust), die Umständlichkeit von Codex, immer wieder dieselben Befehle bestätigen zu müssen (bei Claude kann man Session-Approvals setzen), Context-Management über Agents, einen echten Plan-Modus, die Skills-Funktion mit Lazy Loading. Die Sandbox von Codex ist in der Nutzung verwirrend, und Systemverzeichnisse oder das Internet sind standardmäßig blockiert, weshalb Befehle oft fehlschlagen. Codex verarbeitet Befehle eher mit Python als mit Bash, was die Überwachung erschwert. Wenn Codex bei diesen Funktionen aufholt, denke ich ernsthaft über einen Wechsel nach; bis dahin ist es eher ein großartiges Modell mit einer mittelmäßigen Hülle.

    • Meine Ansicht ist keine Werbung, aber das Internet ist inzwischen so voller Werbung, dass ich mich spontan frage, wie viel OpenAI zahlen müsste, um auf HN so ein Lob als Top-Kommentar zu platzieren.

    • Ich stimme voll und ganz zu. Ich erinnere mich immer noch an die fast magische Veränderung etwa im Juni. Plötzlich folgten Nachtschichten, in denen ich Dinge ausprobierte, die technisch eigentlich nicht gingen, aber konzeptionell möglich schienen. Ich dachte, ich würde Claude Code durch Codex CLI (GPT-5) ersetzen, aber inzwischen fühlt es sich so an, als wäre GPT-5 Codex in meiner Arbeit deutlich besser (allerdings ist meine Branche nischig, deshalb ist Codex bei mehreren zentralen Domänenkenntnissen schwach). Claude Sonnet 4.5 ist für Scaffold-Arbeiten immer noch im Vorteil, aber bei der eigentlichen Implementierung liefert Codex robusteren und saubereren Code. Das Marketingversprechen „auf dem Niveau eines Senior Engineers“ fühlt sich endlich wahr an. Auch preislich ist Codex 40–50 % günstiger. Um Codex jetzt noch zu übertreffen, wäre wohl eine wirklich innovative Weiterentwicklung nötig. Die größte Aufgabe für Agents in Zukunft ist aus meiner Sicht Geschwindigkeit. Wenn CC zwei- bis dreimal schneller wäre, würde ich trotz gleicher Qualität weiter CC nutzen; wenn nicht, ist Codex mein Hauptwerkzeug.

    • Wenn man Codex CLI (gpt-5-codex high) und Claude Code 4.5 sonnet (manchmal opus 4.1) ungefähr zehnmal dieselbe langfristige Aufgabe erledigen lässt und dann beide Modelle auch noch die Arbeit des jeweils anderen bewerten lässt, kam in meinem Fall mit 100%iger Wahrscheinlichkeit heraus, dass Codex besser ist — und zwar laut beiden Modellen. Bei Claude traten durchgehend ausgelassene Anforderungen, Nachlässigkeit und Zerstreutheit auf, während Codex alle Anforderungen erfüllt. Codex ist zwar langsam, aber ich bin viel zufriedener, weil ich Ergebnisse bekomme, die ich nicht immer wieder nachbearbeiten muss.

    • Bei Codex gibt es für mich fast nichts zu tun, und Claude Code ist schnell und liest den „Kontext“ gut. Auch das Testen des eigenen Codes beherrscht Claude besser. Ich hatte erwartet, dass die beiden Modelle ähnlich sein würden, deshalb überrascht mich das Ergebnis.

  • Ich konnte Claude Code letztes Wochenende vorab ausprobieren und habe meine Notizen im Blog geteilt. Es ist ein wirklich solides Produkt und setzt im Grunde eine Web-/Mobile-UI auf Claude Code CLI drauf (mit claude --dangerously-skip-permissions). Anthropic ist sich offenbar bewusst, dass „Claude Code ohne Genehmigung bei jedem einzelnen Schritt“ die Produktivität stark erhöht, und investiert deshalb in Sandboxing.

    • Interessant ist, dass ich genau umgekehrt bei CC bessere Ergebnisse hatte, wenn „allow edits“ deaktiviert war. So kann ich direkt inline selbst Änderungen machen und parallel Code-Review betreiben. Codex eignet sich dagegen eher dafür, wie ein „Anzündholz“ schnell ein Feature zu bauen und es danach zu vergessen. Claude hat dafür die Stärke, die eigentliche Absicht eines Problems zu erfassen, und ist bei Geschwindigkeit und Iterationsschleifen schneller.

    • Mich würde interessieren, ob du ein Gefühl dafür hast, wie problematisch so eine Sandbox-Umgebung werden kann. Datei-/Domain-Allowlists werden doch ihrem Wesen nach offensichtlich zu Schwachstellen führen, die sich über Jahrzehnte wiederholen. Eine Sicherheit auf dem Niveau von Shell-Input per Backslash macht mir Sorgen.

  • Am interessantesten fand ich diesmal drei Dinge: den iOS-Vorstoß von Claude Code, den nahtlosen Übergang vom Web zur CLI und die Open-Source-Freigabe einer nativen OS-Sandbox, die fs- und Netzwerk-Beschränkungen ohne Container umsetzt. Allerdings wird zwar das Einschränken ausgehender Netzwerke betont, zugleich stehen auf der Allowlist Domains wie gist.github.com, über die sich externe Daten leicht exfiltrieren lassen, deshalb wirkt das etwas lückenhaft.

    • Der GitHub-Link zur nativen Sandbox ist hier.

    • Schön, dass es direkt in die App eingebaut wurde. Nach kurzem Ausprobieren scheint es momentan aber noch einige Bugs zu geben.

    • Informationsabfluss kann immer passieren. Die eigentliche Frage ist, ob es für einen Angreifer schwer genug ist, meine Verteidigung zu durchbrechen. Gleichzeitig zögert man aber auch, so etwas sauber zu dokumentieren und zu veröffentlichen, weil genau dieser Inhalt dann wieder in Trainingsdaten zurückfließen könnte.

  • Ich finde, diese Hintergrund-Agents liefern immer noch nicht die Developer Experience, die ich mir wünsche. Es ist unpraktisch, wenn sie in einer Umgebung ohne Zugriff arbeiten, nur per PR in einen Branch pushen und ich das Ganze dann lokal wieder auschecken muss. AI-Coding muss eng an die Entwicklungs-Loop gekoppelt sein, und PRs sind eher für die letzte Prüfung geeignet, nicht als Hauptfluss der Code-Entwicklung. Isolierte Umgebungen, die sich per Cursor/VSCode Remote SSH mit einem Klick verbinden lassen, sollten Standard sein. Tatsächlich hat kein AI-Tool wie Claude jemals beim ersten Versuch alles richtig hinbekommen; man muss immer manuell nacharbeiten. Direkt im IDE zu prüfen und zu verfeinern, gehört zum Alltag.

    • Ich finde es viel einfacher, den Agent direkt per Remote SSH auf einem Test-/Entwicklungsserver laufen zu lassen und dann mit VS Code einen Sanity Check zu machen. Das ist wesentlich praktischer als lokale Entwicklung oder komplexe Setups.

    • Ich war von dieser Ankündigung etwas enttäuscht, denn was ich wirklich will, ist eine Companion-App für Mobil/Web, die an eine CLI-Umgebung angebunden ist. Sie sollte die bestehende Dev-Server-VM per SSH, VSCode Remote und Web (Browser-TTY oder vscode.dev-Tunnel) unterstützen. Es wäre großartig, beim Spazierengehen nachsehen zu können, ob Claude gut arbeitet, und mit Kommentaren wie „LGTM“ dafür zu sorgen, dass es PLAN.md weiter folgt. SSH über den Touchscreen eines Telefons ist mühsam, eine Chat-UI würde völlig reichen. Solche Ansätze habe ich gelegentlich bei GitHub-Projekten oder Show-HN-Posts wie „Happy Coder“ gesehen, aber nie richtig ausprobiert; eine First-Party-Integration wäre mir am liebsten.

    • Ich glaube, dahinter steckt ein grundlegenderes Problem: Die meisten Code-Tests und das meiste Debugging sind remote fast unmöglich. Die Arbeitsumgebung ist ein ephemerer Container ohne meine Daten, nur mit dem Repository. Dann kann das Modell zum Beispiel nicht einfach npm run dev ausführen, eine Webseite öffnen, klicken, Verhalten prüfen, schwere Builds durchführen oder Sitzungen bzw. tägliche Persistenz der Daten nutzen. Das Konzept eines Agents, der in der Cloud läuft, ist okay, aber die Umgebung müsste wesentlich persistenter sein. Die UI selbst müsste Entwicklung von Web-Apps und GUI-basierten Programmen, echtes Ausführen und Interaktion ermöglichen — erst dann benutzt man wirklich einen Computer. Mit den aktuellen Modellen wäre es wahrscheinlich noch zu teuer, so etwas der breiten Masse anzubieten.

    • Ich stimme zu, dass Code-Review und Iteration per PR nicht gut zusammenpassen. Für menschliche Entwickler wurde bis hierhin zwar so gearbeitet, aber für AI-Code oder Coding-Agents passt das nicht. Statt bestehende Formen gewaltsam beizubehalten, brauchen wir eher so etwas wie ein AI-native Git.

    • Manager reagieren allerdings viel stärker auf Verkaufsargumente wie „Story eingeben und einen PR zurückbekommen“.

  • Das YouTube-Demo ist ziemlich komisch, das Demo-Video hier: Der Entwickler gibt einen Prompt ein und erstellt dann einfach einen PR, um Kommentare zu bekommen. Er schaut sich nicht einmal direkt an, was er da gebaut hat. Die Zielgruppe ist sehr eindeutig.

  • Ist das so etwas wie Jules / Codex / Copilot Agent — also ein Modell, bei dem man in der Cloud eine Anfrage stellt und etwas später das Ergebnis als PR bekommt? Auffällig ist, dass am Ende alle bei sehr ähnlichen Funktionssets landen und die endgültige Wahl eher Geschmackssache zu sein scheint. Im Moment habe ich dank Copilot + Codex im Grunde vier autonome Engineers, die ich je nach Schwierigkeitsgrad und Geschwindigkeit der Aufgaben verteilen kann, was meine Produktivität stark erhöht. Und Startups, die „Claude in the cloud“ ausgerufen haben, dürften es künftig schwer haben.

  • Solche Aussagen wie „von 70.000+ Dollar Claude-Code-Nutzung auf codex CLI umgestiegen“ lese ich inzwischen an vielen Stellen. Ich selbst bin im Juni/Juli in Cursor zu CC gewechselt und schon etwa acht Monate vorher aus demselben Grund von VSCode + Copilot weg. Anfangs hielt ich diese Einschätzungen für reines Guerilla-Marketing, aber CC war tatsächlich klar besser als Cursor. Jetzt möchte ich Codex auch einmal ausprobieren. Insgesamt finde ich es gut, dass die schnelle Weiterentwicklung durch mehrere Wettbewerber möglich ist. Kaum zu glauben, dass ich in wenigen Monaten gleich drei IDEs und Workflows ausgetauscht habe — und ehrlich gesagt ist das auch ziemlich ermüdend.

    • OpenAI begrenzt bei gpt-5-codex je nach Abo offenbar, „wie tief es nachdenken kann“, während Anthropic/Claude eher nur die Nutzung begrenzt. Ich teste Codex auch jeden Monat, aber je nach Aufgabe lassen sich die Ergebnisse von Charlie (500 Dollar/Monat) oder Claude oft besser mergen. Die Unterschiede können stark vom Task abhängen.

    • Der IDE-Teil ist inzwischen zum Glück meist entkoppelt, was weniger ermüdend ist. Für Cursor dürfte es schwer werden, allein damit zu konkurrieren, einfach nur Tokens zu verkaufen und den Context aufzuzehren. Ich wechsle zwischen CC und Codex hin und her, aber insgesamt ist Codex herausragend. Aktuell fühlt es sich so an, als gäbe es keinen Ersatz dafür.

  • Bei webbasierten AI-Oberflächen gibt es einen Punkt, den ich mir wünsche: claude.ai und chatgpt.com sollten wie andere SaaS-Produkte eine normale Anmeldung mit Benutzername/Passwort auch ohne 2FA unterstützen, damit Nutzer datenschutzfreundlicher Browser sich einfach und schnell anmelden können. Ich möchte keine externen Authentifizierungen mit fragwürdiger Zuverlässigkeit wie SSO einführen; der Mail-Login von Anthropic oder das MFA von OpenAI unterbrechen den Flow sofort und sind umständlich. Auch das zusätzliche Installieren eines nicht vertrauenswürdigen Desktop-Clients oder Kombinationen mit VM-Sandboxen sind lästig. Direkt im Webbrowser nutzbar zu sein, reicht völlig.

    • Wegen der jüngsten Credential-Stuffing-Angriffe durch Passwortwiederverwendung ist MFA eines der wirksamsten Sicherheitsmittel. Wenn Unternehmen das nicht einführen, können sie von Kreditkarten-Chargebacks überrollt werden. Ich hoffe, dass der Abgleich neuer Passwörter mit Leak-Datenbanken (zum Beispiel wie bei haveibeenpwned) zum Standard wird. Ich nutze einen ähnlichen Workflow, und Seiten mit Passkey-Login kann ich ohne Wartezeit betreten — klare Empfehlung.

    • Wie wäre es mit Unterstützung für WebAuthn? Die aktuelle Login-Methode von claud.ai ist ziemlich unbequem.

  • Ich habe kürzlich etwas Ähnliches für OpenCode gebaut und lasse einfach mal den Open-Source-Link hier, falls es für jemanden nützlich ist. Es kann auch im Frontend-Modus laufen (eine gehostete Version soll bald folgen), und man kann seinen eigenen OpenCode-API-Server angeben und verbinden. Alternativ kann man auch den API-Server selbst hochfahren und per Proxy exponieren, um sicher über das Web darauf zuzugreifen. Die UI ist responsiv, und der Kernpunkt ist, dass man auch unterwegs auf dem Handy direkt AI-Anfragen wie „Mach X für mich“ absenden und sofort verarbeiten lassen kann. Es startet keine eigene Sandbox-Umgebung, aber Nutzer können beliebige Sandboxen ihrer Wahl kombinieren. Anders als Claude Code ist man außerdem frei bei der Wahl des Modells.