ChatGPT meldet „Dieses Projekt konnte nicht für einen lokalen Chat verwendet werden": Ursache und Lösung

„Dieses Projekt konnte nicht für einen lokalen Chat verwendet werden." Diese Meldung ist seit Wochen die Suchanfrage, über die am häufigsten Menschen auf marschfahrt.de landen. Bisher fanden sie die Antwort in einem Abschnitt unseres ChatGPT-Ratgebers, versteckt zwischen Speicher, Tarifen und Plugins. Das ändern wir hiermit: Hier steht alles zu dieser einen Meldung, mit der schnellsten Lösung ganz oben.

Vorweg zu den Quellen: OpenAI hat die Meldung bis heute nirgends erklärt. Alles zur Ursache stammt aus öffentlichen Fehlerberichten im GitHub-Repository von OpenAI, in denen Nutzer die App sehr gründlich untersucht haben. Wir haben diese Berichte am 6. Oktober 2026 ausgewertet und kennzeichnen, was offiziell belegt ist und was nicht. Wir selbst arbeiten am Mac, deshalb zeigen wir den Ablauf als Schema statt als Screenshot.

Kurz gesagt (Stand 6. Oktober 2026)

Ihr habt nichts falsch gemacht: Die Meldung ist ein Fehler der ChatGPT-Desktop-App für Windows, und er ist noch nicht behoben. Sie erscheint, wenn ihr in einem bestehenden ChatGPT-Projekt einen neuen Work-Chat startet, der lokal auf eurem Rechner laufen soll. Die App kopiert dafür das Projekt in einen Ordner auf eurer Festplatte, und eigene Hilfsprogramme der App blockieren genau diesen Ordner.

Am schnellsten weiter kommt ihr so: Führt den Chat im Browser auf chatgpt.com oder in der Cloud weiter, dort funktionieren dieselben Projekte. Wer lokal arbeiten muss, beendet die hängenden Hilfsprogramme node_repl und versucht es sofort noch einmal. Das klappt nach mehreren Berichten zuverlässig, hält aber nur bis zum nächsten neuen Chat.

Welche Lösung zu eurer Lage passt. Die Reihenfolge folgt dem Aufwand: oben das, was in einer Minute erledigt ist.

Wo genau die Meldung auftaucht

Die Meldung kommt nur in der neuen Desktop-App für Windows, nicht im Browser und nicht in den Handy-Apps. Die neue App vereint Chat, Work und Codex. Laut OpenAI erscheinen dort eure bisherigen ChatGPT-Projekte unter Projects, und aus einem Projekt heraus wählt ihr Chat für einen normalen Chat oder Work für einen Work-Chat mit dem Wissen des Projekts. Work kann in der Desktop-App auch lokal laufen, also mit Zugriff auf Dateien und Programme eures Rechners.

Genau dieser Weg scheitert: Projekt öffnen, Work wählen, lokal starten. Statt des neuen Chats kommt die Meldung, im englischen Original „Could not use this project for a local chat". Manchmal steht davor noch eine zweite Meldung, dass der Projektkontext nicht abgeglichen werden konnte. In einem Bericht vom 5. Oktober tauchte sie auch beim Knopf Continue in Work auf, also beim Versuch, einen bestehenden Projekt-Chat in Work fortzusetzen.

Was weiter funktioniert, laut übereinstimmenden Berichten: dasselbe Projekt im Browser und in der iPhone-App, bereits bestehende lokale Chats im Projekt, und neue lokale Work-Chats außerhalb eines Projekts. Manche Nutzer berichten außerdem, dass der erste lokale Chat in einem Projekt noch klappt und erst der zweite scheitert. Das passt zur Ursache, die wir im nächsten Abschnitt erklären.

Warum das passiert

Die App legt für jedes Projekt eine Kopie auf eurem Rechner an und will diese Kopie bei jedem neuen Chat austauschen. Die Kopie liegt unter %USERPROFILE%\.codex\.chatgpt-projects\, mit einem Unterordner je Projekt. Darin stehen die Anweisungen und Dateien des Projekts, damit ein lokaler Chat damit arbeiten kann.

Beim Austausch benennt die App den ganzen Ordner um, und das verweigert Windows, solange ein Programm darin arbeitet. Mehrere Nutzer haben das unabhängig voneinander mit Werkzeugen wie dem Process Monitor nachgewiesen. Der Ablauf: Ein lokaler Chat startet, die App startet dazu Hilfsprogramme, vor allem node_repl.exe, und diese Hilfsprogramme arbeiten im Projektordner. Wenn ihr danach den nächsten Chat im selben Projekt startet, will die App den Ordner umbenennen, Windows meldet einen Zugriffskonflikt, und die App zeigt nur die knappe Meldung. Den eigentlichen Windows-Fehler schreibt sie nicht einmal ins Protokoll, dort steht nur, dass der Abgleich im Dateisystem gescheitert ist.

Der Ablauf hinter der Meldung, wie ihn Nutzer in den offenen Fehlerberichten #45596 und #44736 nachgewiesen haben. Offiziell bestätigt hat OpenAI ihn nicht.

Deshalb hilft es auch nicht, die App neu zu installieren oder Windows zurückzusetzen. Der Fehler steckt in der Art, wie die App ihre eigenen Ordner verwaltet. Jeder neue lokale Chat startet die Hilfsprogramme wieder, und beim nächsten Chat sitzt die Sperre erneut.

Lösung 1: Im Browser oder in der Cloud weiterarbeiten

Öffnet das Projekt auf chatgpt.com und startet den Work-Chat dort. Im Browser läuft Work in der Cloud, eine lokale Kopie des Projekts braucht es dafür nicht. In einem Bericht vom 28. September schreibt ein Nutzer ausdrücklich, dass dieselben Projekte im Browser und in der iPhone-App normal funktionieren, während die Windows-App bei jedem davon scheitert. Cloud-Work-Chats erscheinen laut OpenAI anschließend auch in der Desktop-App und lassen sich dort weiterführen.

Der Haken: In der Cloud hat Work keinen Zugriff auf eure lokalen Dateien und Programme. Wenn ihr Work gerade dafür nutzt, etwa um Dateien auf dem Rechner zu bearbeiten, ist das kein vollwertiger Ersatz. Für Recherche, Entwürfe und alles, was ohnehin im Projekt liegt, reicht es.

Lösung 2: Die hängenden Hilfsprogramme beenden

Beendet nur die Prozesse namens node_repl und startet den Chat sofort noch einmal. Das ist die Lösung mit den meisten Bestätigungen. Ein Nutzer hat sie am 6. Oktober zweimal hintereinander durchgespielt: Meldung, Hilfsprogramme beenden, neuer Versuch klappt, nächster Chat scheitert wieder, wieder beenden, klappt wieder. Bei ihm liefen 13 dieser Prozesse gleichzeitig.

Am schnellsten geht es mit zwei Zeilen in der PowerShell. Öffnet das Startmenü, tippt PowerShell und startet sie. Die erste Zeile zeigt, ob überhaupt solche Prozesse laufen, die zweite beendet sie:

Get-Process node_repl -ErrorAction SilentlyContinue

Get-Process node_repl -ErrorAction SilentlyContinue | Stop-Process -Force

Ohne Befehle geht es über den Task-Manager. Strg, Umschalt und Esc gleichzeitig drücken, zum Reiter mit den Details wechseln, nach node_repl.exe sortieren und jeden Eintrag beenden. Beendet keine anderen Prozesse auf Verdacht, und schaut vorher, dass gerade keine Aufgabe in Work läuft, sonst bricht sie ab.

Rechnet damit, dass ihr das bei jedem neuen Chat im Projekt wiederholen müsst. Der nächste lokale Chat startet die Hilfsprogramme neu, und die Sperre entsteht wieder. Ein Nutzer hat außerdem beobachtet, dass es bei ihm nach dem vollständigen Beenden der App gar keine solchen Prozesse mehr gab und der Fehler trotzdem blieb. Lösung 2 ist also ein Handgriff für den Alltag, keine Reparatur.

Lösung 3: Bestehende Chats weiterführen oder außerhalb des Projekts starten

Bestehende lokale Chats im Projekt laufen weiter, nutzt sie. Der Fehler betrifft nur das Anlegen eines neuen lokalen Chats. Ein Hinweis aus dem OpenAI-Forum: Bittet eine bereits laufende Work-Aufgabe im Projekt, die neue Aufgabe für euch anzulegen. Das umgeht den Weg, auf dem die App den Ordner austauschen will.

Wenn ihr den Projektbezug nicht zwingend braucht, startet den lokalen Work-Chat außerhalb des Projekts. Das funktioniert laut mehreren Berichten problemlos. Die Anweisungen und Dateien des Projekts fehlen dann allerdings. Wer sie braucht, kopiert die wichtigsten Anweisungen in die erste Nachricht und legt die Dateien im Chat neu ab.

Lösung 4: Den Speichermodus des Projekts prüfen

Projekte mit dem Speichermodus Project-only memory erlauben Work grundsätzlich nicht. Das ist der einzige offiziell belegte Sperrgrund. In der Hilfe von OpenAI steht für diesen Modus knapp, dass ChatGPT Work im Projekt nicht verfügbar ist. Geteilte Projekte laufen immer in diesem Modus und lassen sich nicht umstellen. Ein Nutzer hat im September gemeldet, dass ein solches Projekt in der Windows-App genau mit unserer Meldung abgelehnt wird.

So prüft ihr es: Projekt öffnen, das Menü mit den drei Punkten, dann Project settings, dort unter Memory nachsehen. Steht da Project-only memory und ist das Projekt nicht geteilt, könnt ihr auf Default memory zurückstellen. Bedenkt dabei, dass ChatGPT im Projekt dann auch Erinnerungen von außerhalb nutzt. Für geteilte Projekte bleibt nur der Browser.

In Firmen-Workspaces kann zusätzlich der Admin bremsen. Ob jemand in der Desktop-App lokal arbeiten darf, steuert dort die Einstellung Work Local. Fehlt sie, ist lokales Arbeiten gar nicht möglich, egal in welchem Projekt.

Für Fortgeschrittene: den Arbeitsordner der Hilfsprogramme verlegen

Die dauerhafteste Umgehung legt fest, dass die Hilfsprogramme in einem eigenen Ordner arbeiten statt im Projekt. Dafür gibt es in der Konfigurationsdatei config.toml im Ordner .codex die Einstellung cwd je Hilfsprogramm, sie steht in der offiziellen Konfigurationsreferenz. Ein Nutzer hat in Fehlerbericht #44736 genau beschrieben, wie er sie für node_repl und weitere Hilfsprogramme gesetzt hat, danach lief es wieder.

Wenn ihr eigene MCP-Server eingebunden habt, prüft sie zuerst. Ein Nutzer hat am 5. Oktober gezeigt, dass selbst eingetragene Server ohne eigene cwd-Angabe im Projektordner starten und ihn ebenfalls sperren. Mit einer cwd-Zeile je Server, die auf einen Ordner außerhalb von .chatgpt-projects zeigt, ließen sich bei ihm zwei Chats hintereinander anlegen.

Lasst die Finger davon, wenn ihr mit Konfigurationsdateien nicht vertraut seid. Die App schreibt einen Teil dieser Einstellungen beim Start selbst neu, und nach Updates waren sie bei einem Nutzer viermal wieder weg. Ein falscher Eintrag kann außerdem dazu führen, dass gar keine lokale Aufgabe mehr startet. Sichert die Datei vorher und rechnet damit, dass ihr nach jedem Update nachbessern müsst.

Was nicht hilft

Spart euch die großen Maßnahmen, sie haben in keinem uns bekannten Bericht etwas gebracht. Dazu gehören: die App reparieren oder neu installieren, Windows zurücksetzen, sich ab- und wieder anmelden, das Projekt neu anlegen und den Ordner .chatgpt-projects löschen oder umbenennen. Ein Nutzer hat mit einem frisch angelegten, leeren Projekt nachgestellt, dass der Fehler auch dort auftritt.

Auch das Update allein löst es bisher nicht. OpenAI empfiehlt allgemein, die App über Menu > Check for Updates zu aktualisieren, wenn Funktionen fehlen. Das ist sinnvoll, aber der Fehler tritt laut den Berichten in allen gemeldeten Builds seit Juli auf, zuletzt am 5. Oktober im Build 26.930.3930.0.

Was laut den Fehlerberichten hilft und was nicht. Grundlage sind die offenen Meldungen #34499, #35127, #42215, #44736, #45596 und #49047 im GitHub-Repository openai/codex, Stand 6. Oktober 2026.

Betrifft das auch den Mac?

Nach allem, was öffentlich bekannt ist, nein. Alle Fehlerberichte mit dieser Meldung im GitHub-Repository von OpenAI stammen von Windows-Rechnern, die Ursache hängt an der Art, wie Windows Ordner sperrt. Die Mac-App hat eigene Macken bei Projekten, etwa Projektdateien, die nicht abgeglichen werden, aber nicht diese.

Ist der Fehler behoben?

Nein, Stand 6. Oktober 2026 ist er offen. Der älteste Bericht stammt vom 21. Juli 2026, inzwischen gibt es mehr als ein Dutzend Meldungen dazu, alle offen. Geantwortet hat OpenAI in keiner davon. Immerhin trägt einer der Berichte inzwischen die Markierung „Papercuts 2026", also die Einordnung als kleiner, aber störender Fehler. Ob und wann daraus ein Fix wird, ist nicht bekannt.

Woran ihr den Fix erkennt: Startet nach einem App-Update zwei lokale Work-Chats hintereinander im selben Projekt, ohne vorher Prozesse zu beenden. Klappt auch der zweite, ist der Fehler bei euch behoben. Wir prüfen den Stand regelmäßig und tragen Änderungen hier ein.

Was sich geändert hat und was das für euch heißt

6. Oktober 2026: Die Umgehung mit dem Beenden von node_repl ist mehrfach bestätigt, auch wiederholt hintereinander. Für euch heißt das: Lösung 2 ist der verlässlichste Weg, wenn ihr lokal arbeiten müsst.

5. Oktober 2026: Der Fehler tritt im damals aktuellen Build 26.930.3930.0 weiter auf. Neu bekannt: Eigene MCP-Server ohne cwd-Angabe sperren den Projektordner ebenfalls. Wer solche Server eingebunden hat, sollte sie zuerst prüfen.

28. September 2026: Ein Bericht zeigt, dass auch gewöhnliche Cloud-Projekte betroffen sind, die nie mit einem lokalen Ordner verbunden waren, und kurz darauf auch frisch angelegte, leere Projekte. Für euch heißt das: Es liegt nicht an euren Projektinhalten, Aufräumen im Projekt bringt nichts.

21. Juli 2026: Erster Fehlerbericht aus der Windows-App. Für euch heißt das: Wer seit dem Sommer damit kämpft, ist kein Einzelfall.

Stand dieser Fassung: 6. Oktober 2026. Mehr zum Arbeiten mit Projekten, Speicher und Work steht in unserem ChatGPT-Ratgeber.

KI im Betrieb, ohne an Fehlermeldungen hängen zu bleiben

Solche Fehler zeigen, wie schnell sich KI-Werkzeuge gerade ändern, und wie viel Zeit es kostet, hinterherzukommen. Wir richten KI-Werkzeuge und Automationen so ein, dass sie im Alltag eures Betriebs zuverlässig laufen, und erklären euren Leuten, was sie tun können, wenn doch etwas hakt. Dazu passt: ChatGPT richtig nutzen · Leistung: KI und Automatisierung

Schreibt uns, was ihr vorhabt, über unser Kontaktformular. Wir antworten innerhalb von 24 Stunden, persönlich und ohne Vertriebsgespräch.