VS Code aufräumen: Erweiterungen, Caches und der Müll alter Workspaces

Wo VS Code die Gigabytes versteckt

Alles, was VS Code speichert, liegt unter %APPDATA%\Code, und vier Unterordner treiben den Großteil des Wachstums. User\workspaceStorage hält ein Zustandsverzeichnis für jeden jemals geöffneten Ordner — gelöschte Projekte eingeschlossen —, und nichts räumt es automatisch auf. Cache, Code Cache und GPUCache sind die üblichen Chromium-Verdächtigen: ständig im Neuaufbau und jederzeit leerbar. logs legt für jede Sitzung einen neuen Ordner an, und CachedExtensionVSIXs hortet die Installationspakete von Erweiterungs-Updates, lange nachdem sie gebraucht wurden.

Dazu kommt %USERPROFILE%\.vscode\extensions, wo nach Updates gelegentlich verwaiste Versionen überleben — und eine schwergewichtige Installation überschreitet 5 GB, ohne Sie je zu warnen. An keinem dieser Orte liegen Ihre Einstellungen oder Tastenkombinationen: Die wohnen in User\settings.json und bleiben von jeder Cache-Räumung unberührt.

• %APPDATA%\Code\User\workspaceStorage — Projektzustand für jeden jemals geöffneten Ordner; der größte Einzelhort auf alten Maschinen
• %APPDATA%\Code\Cache, Code Cache, GPUCache — Chromium-Caches; bedenkenlos löschbar, beim nächsten Start neu aufgebaut
• %APPDATA%\Code\logs — ein Ordner pro Sitzung; nichts räumt sie je von selbst auf
• %APPDATA%\Code\CachedExtensionVSIXs — heruntergeladene Erweiterungs-Installer, die nach Updates liegenbleiben
• %USERPROFILE%\.vscode\extensions — verwaiste alte Erweiterungsversionen nach Updates
• .history-Ordner von Local History — in Ihren Projekten, sofern die Erweiterung läuft; alte Schnappschüsse stapeln sich im Repo

Erweiterungen sind der echte Performancetax

Speicherplatz ist die kleinere Hälfte des Problems. Jede Erweiterung lädt in einen gemeinsamen Extension-Host-Prozess, und Schwergewichte — Language Server wie Pylance, C/C++ oder der TypeScript-Server, dazu Linter und Themes — verbrauchen je eigene Hundert Megabytes RAM, egal ob Sie sie nutzen. Auch der Start zieht sich: Der Befehl Developer: Startup Performance zeigt millisekundengenau, was welche Erweiterung kostet, und die Zahlen überraschen Leute mit sechzig Erweiterungen regelmäßig.

Prüfen Sie mit code --list-extensions und deinstallieren Sie, statt nur zu deaktivieren — eine deaktivierte Erweiterung bleibt auf der Platte und lädt manchmal trotzdem. Für Mono-Installationen sind Profile die ehrliche Antwort: ein mageres Standardprofil plus getrennte Profile für Python, Schreiben und Terminalarbeit, jedes nur mit den Erweiterungen, die es wirklich braucht.

Eine Räumroutine, die hält

Zweimal jährlich genügt: VS Code schließen, die Inhalte von Cache, Code Cache, GPUCache, logs und CachedExtensionVSIXs löschen und workspaceStorage komplett leeren — Sie verlieren Zustände wie die Taskhistorie je Projekt, nicht aber Einstellungen. Nichts wird neu installiert, nichts zurückgesetzt. Der Editor baut beim nächsten Start nach, was er braucht, und der erste Start nach der Räumung ist um Sekunden langsamer — genau einmal.

Damit es schlank bleibt, behandeln Sie Erweiterungen wie installierte Programme, nicht wie Sticker: Jede braucht einen aktuellen Existenzgrund. Und vor dem Umzug auf eine neue Maschine zuerst aufräumen — sonst kopieren Sie drei Jahre workspaceStorage von Projekten mit, die 2023 gestorben sind.

Fragen und Antworten

Weiterlesen