Claude Code für VSCode veröffentlicht

• Eine Erweiterung, die Claude Code in VSCode integriert und so das Coding-Erlebnis von Entwickler:innen verbessert
• Funktioniert nur, wenn Claude Code separat installiert ist

Hauptfunktionen

• Automatische Installation: Wenn Claude Code im VSCode-Terminal ausgeführt wird, wird die Erweiterung automatisch erkannt und installiert
• Kontextbewusstsein für Auswahlbereiche: Im Editor ausgewählter Text wird automatisch in den Eingabekontext von Claude aufgenommen
• Diff-Ansicht unterstützt: Codeänderungen (Diffs) können direkt im integrierten Viewer von VSCode geprüft werden
• Tastenkürzel: Mit Shortcuts wie Alt+Cmd+K lässt sich ausgewählter Code einfach an den Claude-Prompt übergeben
• Tab-Erkennung: Claude erkennt Informationen über in VSCode geöffnete Dateien und kann dadurch situationsgerechte Code-Unterstützung bieten
• Konfigurationsoption: Wenn in /config das Diff-Tool auf auto gesetzt wird, lassen sich Funktionen rund um die IDE-Integration einfach aktivieren

• Es handelt sich um eine frühe Veröffentlichung (Early Release), daher können bei der Nutzung Bugs auftreten oder einige Funktionen noch unvollständig sein

[digitect38]

Ein klarer Unterschied zu Cursor

1. Cursor ist an VSCode gebunden. Claude Code hingegen funktioniert als CLI (Command Line Interface) und kann daher mit jedem Tool verwendet werden.

2. Cursor nutzt faktisch andere LLMs, während Claude Code auf Claude spezialisiert ist. Vergleicht man jedoch die tatsächliche Leistung, liegt Claude Code klar vorn. Das gilt auch im Vergleich zu Gemini 2.5 Pro (auf Basis von .NET; je nach Sprache kann es Unterschiede geben).

[bluekai17]

Was ist dann der Unterschied zu Cursor?

[iolothebard]

Nein, für Windows (nicht WSL) wird es nicht entwickelt, stattdessen treiben sie ständig irgendeinen anderen Kram voran … -,. -;;;

[wahihi]

WSL ist auch ein Teil des Windows-Betriebssystems, aber offenbar weiß man nicht, wie man es benutzt … Wenn man nur mit GUI entwickelt, kennt man die CLI vielleicht gar nicht …

[yeorinhieut]

Bei der Nutzung von WSL gibt es auch das Problem einer sehr schlechten Dateisystem-Performance (wsl2), außerdem hat es den Nachteil, bei der Virtualisierung von Hyper-V abhängig zu sein. Es gibt auch viele Fälle, in denen WSL nicht verwendet werden kann.

[namojo]

Sehe ich genauso. Bei uns in der Firma ist die Nutzung von WSL auch verboten, deshalb habe ich es dann aufgegeben.
Nachdem ich mich irgendwie durch das SSL-Zertifikat gekämpft hatte, stellte sich heraus, dass WSL gar nicht funktioniert.

[ng0301]

hahaha, dem stimme ich total zu

[melong0124]

Worin dürfte der Unterschied zu Git Copilot liegen?

[digitect38]

Copilot ist auf MS-IDEs spezialisiert und dabei buchstäblich eher auf Anfänger-Niveau, während Claude in der CLI / Git Bash läuft und daher in verschiedenen Umgebungen nutzbar ist; die Coding-Fähigkeiten sind vergleichsweise höher.

[kimjoin2]

Es gibt auch ein IntelliJ-Plugin.
Der Unterschied zu einer einfachen CLI ist, dass es die Datei oder Zeile, die man in der IDE gerade ansieht oder ausgewählt hat, direkt erkennt.
Natürlich kann man es auch in einem normalen Terminal ausführen und die Anbindung mit dem Befehl /ide starten.

[GN⁺]

Hacker-News-Kommentare

• Ich halte es für die falsche Richtung, agentenbasiertes Coding in bestehende IDEs zu integrieren. Besser ist ein Ansatz, bei dem mehrere Git-Worktrees verwaltet werden und die jeweiligen Agents gleichzeitig laufen. Man muss dann nicht über 20 Minuten darauf warten, dass Claude Code eine Aufgabe abschließt. Deshalb habe ich selbst eine UI dafür gebaut, und sie entwickelt sich allmählich zu einer neuen Art von IDE, in der mehrere Agents verwaltet und geprüft werden. Anders als bisher arbeitet man nicht mehr nur an einer Sache gleichzeitig. https://github.com/stravu/crystal
  • Ich persönlich sehe das anders. Ich nutze Cursor täglich für kommerzielle Projekte. Background-Agents sind in bestimmten Situationen zwar nützlich, verursachen aber meistens nur Ablenkung. Meine bevorzugte Art zu programmieren ist, mich auf ein Ziel zu konzentrieren und mich iterativ der Lösung zu nähern. Während ich darauf warte, dass eine Aufgabe abgeschlossen wird, schaue ich in Dokumentation oder verwandte Informationen, um über den nächsten Schritt nachzudenken. Es ist auch extrem wichtig, den aktuellen Stand genau zu verstehen, indem man bestehenden Code oder Änderungen prüft. Das Konzept, für jede Aufgabe mehrere Agents zu verwalten, passt nicht zu meinem Stil. Es gibt dabei zu viele Kontextwechsel und zu viel Multitasking.
  • Bei solchen Workflow-Vorschlägen frage ich mich immer, wie ich meinen persönlichen Kontext verwalten soll. Selbst bei Code-Reviews von Kollegen versuche ich nicht, jeden Code vollständig zu verstehen und zu verifizieren, sondern prüfe meistens nur schnell auf grobe Fehler wie Codestil oder Best Practices. Deshalb kann ich viele PRs pro Tag schnell durchsehen. Bei wichtigeren Aufgaben, für die ich verantwortlich bin, teste ich den Branch und prüfe die Implementierung sorgfältig. Da ich das bei jedem PR-Update wiederhole, kostet das viel Zeit. Wenn mehrere Agents gleichzeitig Diffs vorschlagen, frage ich mich, wie man vor allem bei notwendiger Verifikation mit den Kontextwechseln umgehen soll und wie Modulabhängigkeiten verwaltet werden, wenn ein Update andere Aufgaben subtil beeinflusst.
  • Dieselbe Arbeitsweise ließe sich auch als IDE-Plugin umsetzen.
  • Tolles Tool! Mich würde interessieren, warum du nicht das Claude Code TS SDK verwendet hast. Das Paket scheint installiert zu sein, aber die Struktur wirkt so, als würde der claude-Befehl separat direkt ausgeführt. Nebenbei würde ich empfehlen, dir auch electron-trpc anzusehen. Damit wird die IPC-Verarbeitung deutlich einfacher.
  • Das Tool ist ebenfalls großartig, aber es löst ein anderes Problem. Bei Background-Agents gibt es zwei große Probleme. 1) Es gibt eine hohe Einstiegshürde, um getrennte Umgebungen sauber einzurichten. Je nach Projekt variiert der Schwierigkeitsgrad stark — von der einfachen Wahl eines Containers bis hin zur Hölle, alle Abhängigkeiten zu konfigurieren. Arbeitet man dagegen in der IDE, ist normalerweise schon alles vorhanden. 2) Die Leute müssen erst lernen, wie der Agent den Code aufbaut. Wenn der Agent in der IDE läuft und ich ihm in Echtzeit Hinweise geben oder Korrekturen liefern kann, hilft das langfristig viel mehr als ein Background-Agent.
• Ich wünsche mir Folgendes: eine Umgebung mit starker Unterstützung für kontextbezogene Wechsel auf Basis von Git-Worktrees im selben IDE-Fenster, ein Framework, mit dem sich terminalbasierte Agents an jeden Worktree-Branch hängen lassen, und letztlich eine Entwicklung hin zu besseren offenen Protokollen für Diffs, Berechtigungsanfragen und Fortschrittsbenachrichtigungen, dazu eine Seitenleiste zur Überwachung von Agent-Status und Benachrichtigungen pro Worktree-Branch sowie eine Oberfläche, mit der man auf Agent-Nachrichten über mehrere Branches hinweg schnell wie auf Notifications reagieren kann. Solche Funktionen gibt es in eigenständigen Agent-Managern, aber wenn man als echter Engineer direkt in die Arbeit springen will, kann man solche Tools nicht wirklich voll nutzen. Es braucht auch eine Integration mit Browser-Testfenstern oder mobilen Emulator-/Simulator-Instanzen je Branch. Dazu kommen modellgestützte Codevervollständigung mit geringer Latenz, Unterstützung für verschiedene Language Server und ein Erweiterungs-Ökosystem, das als hochwertige IDE taugt. Derzeit verteile ich Windsurf, Claude Agent, Webbrowser und mobile Simulatoren jeweils getrennt auf mehrere macOS-Desktops. Das ist sehr umständlich.
  • Ich will einen Coding-Agent mit Debugging-Funktionen. Er soll den Stack verfolgen, lokale Variablen und Argumentwerte ansehen und statt print oder assert wirklich hineinschauen können, was intern passiert.
  • Zu der Funktion, über mehrere Branches hinweg schnell wie auf Notifications auf Agent-Nachrichten zu reagieren: Ich hatte auch versucht, ein Plugin für VSCode zu bauen. Es sollte Claude direkt zu Datei und Zeile springen lassen. Bis zu einem gewissen Grad funktionierte es, hatte aber ständig Probleme mit Hängern.
• Ich verstehe nicht wirklich, worin der tatsächliche Unterschied zwischen Cursor und Claude Code besteht. Ich habe beide genutzt, und weil meine Firma es unterstützt, bin ich einfach zu Cursor gewechselt. Abgesehen von CLI versus UI konnte ich keinen besonderen Unterschied feststellen, denn beide können mehrere Dateien auf einmal bearbeiten. Ich hoffe, diese unbequeme Übergangsphase, in der man mehrere Editoren gleichzeitig nutzt oder zwischen JetBrains und Cursor wechseln muss, endet bald.
  • In Qualität und Nutzbarkeit unterscheiden sie sich stark. Claude Code ist vollständig agentisch. Man gibt ihm eine Aufgabe, und er implementiert das Ganze selbstständig und erzeugt ziemlich brauchbaren, funktionierenden Code. Er kann testen, committen, Befehle ausführen, auf entfernte Systeme zugreifen, debuggen usw. Er optimiert den Token-Verbrauch nicht, deshalb liefert er im ersten Versuch oft hochwertigeren Code als Cursor, ist dafür aber auch teurer. Der Agent-Modus von Cursor ist noch in einer frühen Phase. Cursor ist eher ein Tool zur Dateibearbeitung, Claude Code eher wie ein Junior-Entwickler.
  • Ich verwende oft beide Tools zusammen. Cursor ist die IDE, Claude Code läuft im Terminal der IDE. Auch bei gleicher Basis-Modellfamilie gibt es Unterschiede in der Agent-Performance, der Analyse der Codebasis, dem Einsatz von Untermodellen und der Tool-Integration.
  • Ich finde es erstaunlich, dass du kaum Unterschiede bemerkst. Für mich ist Claude in jeder Hinsicht überlegen. Ich arbeite hauptsächlich mit scala, python, js und dart. Mit Claude habe ich einen extrem produktiven Assistenten. Besonders für kleine bis mittlere Änderungen ist es sehr nützlich. Wenn man gut plant, fühlt es sich fast magisch an. Es produziert zwar etwas Code-Duplikation, aber das ist auch schon alles. Cursor brauchte zu viel Nachbearbeitung und hat mich am Ende eher verlangsamt.
  • Claude Code ist wirklich beeindruckend. Es fühlt sich an, als säße ein weiterer Programmierer mit mir im Terminal. Perfekt ist es nicht, und man muss ihm helfen, bis es wirklich versteht, was man möchte. Aber wenn der Kontext einmal stimmt, ist es wirklich erstaunlich. In meinem Fall habe ich ihm das Projekt nicht einmal vollständig erklärt und nutze es weder für TypeScript noch für Webentwicklung.
  • Bei Cursor muss man auf eine separate IDE wechseln, es sei denn, man nutzt ohnehin VSCode. Claude Code (oder Aider) bearbeitet dagegen die Projektdateien direkt im Terminal parallel zur aktuellen IDE. Ich arbeite mit vim+tmux+bash und bevorzuge daher CLI-Assistenten, aber derselbe Vorteil gilt auch für Leute, die eine andere GUI-IDE als VSCode verwenden.
• Letzte Woche war ich eher schockiert, dass es kaum Gegenreaktionen gab, als github Premium-Request-Limits für Copilot eingeführt hat. Ich vermute, dass es deutlich mehr Widerstand geben wird, sobald mehr Leute tatsächlich an diese Limits stoßen. Gut, dass es Konkurrenzprodukte gibt.
  • Bei Claude Code können auch 10 Dollar in einem einzigen Lauf blitzschnell verschwinden.
• Ich frage mich, ob es gegenüber VSCode Copilot im Agent-Modus mit Claude Sonnet 3.7 oder 4 besondere Vorteile gibt. Ich möchte wissen, ob mir etwas entgeht.
  • Man muss Claude Code selbst erlebt haben, um diese Frage beantworten zu können. Es bringt nichts, hier nur darüber zu diskutieren. Wenn du hauptsächlich im Linux-Terminal arbeitest, wirst du sofort darauf anspringen. Lies unbedingt auch die Dokumentation. Nutze CLAUDE.md, lege große Aufgaben als Planungsdokumente im Markup-Format an und arbeite iterativ mit Planung, Überarbeitung und Implementierung. Wenn du dich dem Context-Limit näherst, ist es viel effizienter, den Speicher in eine Datei zu schreiben, /clear auszuführen und ihn anschließend wieder einzulesen.
  • Ich habe versucht, Playwright MCP mit dem Copilot-Agent-Modus zu verbinden, bin aber gescheitert. Es ließ sich installieren und erschien auch in der Tool-Auswahl, aber am Ende hat Copilot den Zugriff auf die Funktionalität nicht erlaubt.
• Ich frage mich, was der Vorteil dieser Lösung gegenüber der Nutzung des Claude-Backends im Copilot-Agent-Modus ist.
  • Die anderen Erklärungen in diesem Thread — insbesondere https://news.ycombinator.com/item?id=44353972 — gelten auch für VSCode Copilot.
  • Nach ein paar Tagen Nutzung hat diese Integration für mich vor allem das Problem gelöst, dass ich Dateien einzeln öffnen musste, um Updates zu prüfen. Im Terminal-Modus lief alles im Hintergrund, sodass man nicht wusste, was gerade geschah, aber in der integrierten IDE kann man alles in Echtzeit sehen. Allerdings waren die Namen, die der Agent vergibt (z. B. Pondering, Twerking, Juggling usw.), anfangs zwar neuartig, wurden aber schnell nutzlos.
• Etwas off-topic, aber ich würde gern wissen, ob hier jemand Roo in VSCode verwendet. Und mich interessiert, ob die Browser-Funktion von Roo gut mit dem von GitHub Copilot bereitgestellten Claude zusammenspielt.
• Soweit ich weiß, wird das automatisch installiert, wenn man Claude Code in VSCode oder Cursor ausführt. Man muss es also nicht extra suchen und installieren, oder?
  • Dass Claude Code beim Start in VSCode automatisch installiert wird, fühlt sich das nicht ein wenig übergriffig an?
  • Ja. Das steht auch auf der Erweiterungs-Webseite.

  Auto-installation: When you launch Claude Code from within VSCode’s terminal, it automatically detects and installs the extension
  

• Mir fällt auf, dass sich mein Workflow verändert, seit ich verstanden habe, dass Claude Code mehrere Schritte auf einmal erfassen kann. Statt pro Datei zu denken, bewege ich mich immer mehr hin zu einzelnen Handlungseinheiten wie „Modul aufteilen, Tests schreiben, Aufrufer refaktorieren“. Claude versteht das ebenfalls als eine Einheit, zumindest im Modus mit maximalem Aufwand. Diese Veränderung verschiebt meinen Ansatz beim Programmieren schrittweise. Ich sorge mich weniger um Syntax, schreibe mehr Scaffolding und bündele mehrere Aufgaben zu Paketen. Das ist subtil, hat aber langfristig große Auswirkungen. Ich frage mich, wie schnell der Zeitpunkt kommt, an dem wir Codebasen bewusst so strukturieren, dass LLM-Agents sie besser durchsuchen können — flach, mit minimalen Umwegen, deklarativen Metadaten usw.
  • Bevor man fragt, wann das Zukunft wird: Es passiert bereits. Armin Ronacher schreibt in Python inzwischen häufiger in Go, weil LLMs Go besser verstehen. Ein Kollege von mir hat seine Desktop-App auch nach Rust verlagert, weil sie dank Tooling und Typsystem für Agents leichter zu navigieren ist. Der Fokus verschiebt sich bereits in Richtung Dokumentation, die für AI gut lesbar ist.
  • Ich denke darüber auch ständig nach, seit ich immer wieder höre, dass LLMs mit Sprachen wie Go besonders gut arbeiten — also mit klaren statischen Typen, knapper Syntax und einem konsistenten Schreibstil. Je weniger unnötige Komplexität sich aus den gewählten Tools ergibt — Sprache, Framework, Bibliotheken usw. — desto mehr unserer geistigen Ressourcen können wir in die eigentliche Problemlösung stecken.
• Ich freue mich, dass Claude Code auch für Jetbrains kommt! https://plugins.jetbrains.com/plugin/27310-claude-code-beta-
  • Ich verstehe nicht, warum dieser Kommentar so viele Downvotes bekommt. Ich freue mich ebenfalls darüber. Danke fürs Teilen.

[namojo]

Wenn man Claude Code nutzt, scheint mir so etwas wie ein MSA-ähnliches Konzept am effizientesten zu sein: alles so weit wie möglich in Einheiten auf Mikroservice-Ebene aufzuteilen und jede davon als eine eigene Einheit zu behandeln.