Praxis & Workflow

Claude Cowork auf Windows 11

Die CLAUDE.md Dateien — ja wo sind sie denn?

Cowork ist nicht einfach ein Chat

Wer Claude Cowork zum ersten Mal startet, könnte denken: ein weiteres Chat-Fenster, diesmal mit Dateizugriff. Das stimmt — und stimmt gleichzeitig überhaupt nicht.

Cowork läuft in einer eigenen Linux-VM auf dem lokalen Rechner. Es ist kein Windows-Programm, das nativ auf das Dateisystem zugreift, sondern ein Linux-Agent, der über gemountete Pfade an deine Windows-Ordner kommt. Das hat Konsequenzen — und wer die nicht kennt, produziert Fehler, die schwer zu finden sind.

Die Architektur in 30 Sekunden

Dein Windows-Arbeitsordner wird in die Linux-VM gemountet. Cowork sieht ihn unter /sessions/.../mnt/..., nicht unter C:\Users\.... Zusätzlich gibt es MCP-Server (Model Context Protocol), die als Brücke zwischen der VM und externen Diensten fungieren — zum Beispiel ein Desktop Commander für native Windows-Dateioperationen oder ein Kirby-MCP für direkten CMS-Zugriff.

Das bedeutet: Cowork operiert in einer Sandbox. Es hat keinen direkten Zugriff auf Netzlaufwerke, keine Registry, kein PowerShell im klassischen Sinn. Alles, was über den gemounteten Ordner hinausgeht, braucht einen MCP-Server als Vermittler.

CLAUDE.md — die Konfigurationsdateien

Cowork liest beim Start Konfigurationsdateien im Markdown-Format, die das Verhalten steuern. Drei Ebenen:

1. Custom Instructions (global)

Die höchste Ebene. Wird bei jedem Sessionstart geladen, unabhängig vom Projekt. Erreichbar über die Cowork-Einstellungen in der Desktop-App. Hier gehört alles rein, was projektübergreifend gilt: Betriebssystem-Besonderheiten, Pfadkonventionen, Firmenkontext, Prompt-Regeln.

2. Benutzerweit: ~/.claude/CLAUDE.md

Eine globale CLAUDE.md im Claude-Konfigurationsverzeichnis des Benutzers. Wird ebenfalls bei jedem Start gelesen.

3. Projektspezifisch: CLAUDE.md im Projektordner

Liegt direkt im Root des jeweiligen Projekts. Enthält nur, was für dieses eine Projekt relevant ist — spezifische Pfade, Abhängigkeiten, Workflows.

Wo liegen die Dateien auf Windows?

Das ist die Frage, die überraschend schwer zu beantworten ist. Die CLAUDE.md-Dateien der einzelnen Projekte liegen nicht im Projektordner selbst, sondern im AppData-Verzeichnis der Claude Desktop App:

%AppData%\Claude\ bzw. im lokalen Äquivalent.

Wer sie sucht, wird im Projektordner nicht fündig — und das ist verwirrend, wenn man es nicht weiss. Am schnellsten findet man alle CLAUDE.md-Dateien per PowerShell:

Get-ChildItem -Path $env:APPDATA\Claude -Recurse -Filter "CLAUDE.md"

Oder für den Dev-Space:

Get-ChildItem -Path "C:\Users\<username>\dev-space" -Recurse -Filter "CLAUDE.md" -File

Was gehört in die Custom Instructions?

Aus der Praxis: Alles, was man sonst in jeder neuen Session von Hand erklären müsste. Ein bewährtes Schema:

Session-Verhalten — Wie soll Cowork mit Rückfragen umgehen? Wann implementieren, wann diskutieren?

Arbeitsumgebung — OS, wichtige Pfade, Tool-Zuordnungen (welcher MCP-Server wofür)

Dateisystem-Besonderheiten — Bei Windows-Netzlaufwerken mit Leerzeichen und Umlauten in Pfaden ist das überlebenswichtig. Native MCP-Tools statt Shell-Befehle für Dateioperationen, immer Anführungszeichen um Pfade, UTF-8 Codepage für Batch-Dateien.

Fachlicher Kontext — Firmenspezifische Begriffe, Produktnamen, Systeme. Cowork kann nicht raten, was „CAMA“ oder „KOM“ bedeutet.

Script-Konventionen — Codepage, relative Pfade, Variablen statt Hardcoded Paths.

Die Plugin-Falle

Ein konkreter Fall aus der Praxis: Cowork startete plötzlich mit 30 Sekunden Verzögerung und meldete bei jedem MCP-Verbindungsversuch „Server not connected“. Die Ursache war ein 3rd-Party-Plugin — ein alternativer File Browser, der als MCP-Server registriert war.

Das Plugin hat beim Start einen Handshake-Loop ausgelöst: Starten, Initialize, Crash, Neustart — drei bis vier Mal pro Sekunde, bevor der eigentliche MCP-Stack überhaupt zum Zug kam. Ergebnis: nichts ging mehr.

Die Lösung war simpel: Plugin deinstallieren, Neustart. Problem weg, 30 Sekunden Vorlauf weg.

Die Lektion: Cowork hat (noch) keinen Zertifizierungsprozess für Plugins. Was in der Plugin-Liste auftaucht, ist nicht zwingend getestet oder kompatibel. Im Zweifel ist weniger mehr — und ein Blick in die MCP-Logs (Filesystem-Einträge mit Timestamps) zeigt schnell, ob ein Plugin den Stack blockiert.

Geräteübergreifend? Nein.

Cowork-Sessions sind an das Gerät gebunden. Custom Instructions werden lokal gespeichert und nicht zwischen Rechnern synchronisiert. Cross-Device-Sync steht auf Anthropics Roadmap, ist aber noch nicht verfügbar.

Das ist bei OS-spezifischen Konfigurationen sogar ein Vorteil: Eine Windows-CLAUDE.md mit K:\-Pfaden und CMD-Regeln hat auf einem Mac nichts verloren. Wer beide Plattformen nutzt, braucht zwei separate Konfigurationen.

Fazit

Cowork ist mächtig, aber nicht selbsterklärend. Die Linux-VM-Architektur, die versteckten Konfigurationsdateien und die fehlende Plugin-Validierung sind Stolpersteine, die man einmal verstehen muss. Danach läuft es — aber eben nur, wenn die Custom Instructions sauber aufgesetzt sind und man weiss, wo welche Datei welche Rolle spielt.