[Desktop App] "Working directory no longer exists" error on startup with no UI option to change root directory — workaround & feature requests

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/62086
2. https://github.com/anthropics/claude-code/issues/54461
3. https://github.com/anthropics/claude-code/issues/65399

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a maintainer — your config-file workaround is correct, but there's a simpler and lower-risk recovery worth adding for anyone hitting this, because hand-editing three JSON files (and getting the URL-encoding right in workspace.json) can leave the app more broken if a path is mistyped.
Simplest recovery: make the old path exist again, instead of editing config. The startup check is just "does the configured root directory exist?" — so you usually don't need to repoint anything:

• If the folder was deleted: recreate an empty directory at the exact original path (mkdir/New-Item with the same name and location). The app finds it and starts. You can then open a valid project from inside and let the old empty folder go.
• If the folder was moved or renamed: move/rename it back to the original path, start the app, and relocate properly from within the UI if it supports it. (If it was on a OneDrive/Dropbox-synced path, the sync client relocating or de-duplicating the folder is a common trigger for this — worth checking before you assume it was you.)

Only fall back to editing workspace.json / storage.json / the session local_*.json (cwd/originCwd) if you genuinely can't restore the old path. If you do edit them, copy the files first — a single bad URL-encoded path there is harder to diagnose than the original error.
The underlying feature request stands (a startup that offers "pick a new folder" instead of hard-failing, the way most editors do), but the recreate-the-path trick gets people unstuck in seconds without touching config.

Confirming this exact failure mode on Windows (Desktop app, June 2026).

I had been working for weeks under the assumption I was editing my real project, only to discover every new local session the Desktop app created had silently reused the working directory from my very first session months earlier — a folder that had since become a stale, abandoned duplicate of my actual codebase (which lives elsewhere, under active git history with 100+ files vs. 14 in the stale one). The Desktop app never offered a directory picker when creating new sessions; it just inherited whatever cwd was last used. I confirmed this by inspecting claude-code-sessions\<account-id>\<id>\local_*.json — every one of my last 11 local sessions had the identical stale cwd, going back weeks.

When I tried to fix it by renaming the stale folder (so new sessions would stop defaulting to it), all of my local sessions became unusable, not just the one tied to that folder. I had to rename it back to its original name to restore access to any Claude Code session at all. This matches the "Working directory no longer exists" failure described in this issue exactly, with no recovery UI offered.

Two changes would prevent this for other users:

1. A directory picker (or at least a confirmation step) when creating a new local session, instead of silently reusing the last-used cwd.
2. Renaming/moving a folder referenced by an old session should only break that session, not every session tracked by the app.

Current workaround: launching claude from a terminal (cd <project> && claude) instead of the Desktop app's "New session" button, since the CLI prompts for/accepts an explicit directory and doesn't have this silent-reuse behavior.

I'm on Windows 11 and using Claude 1.18286.0 (259c3f) 2026-07-02T07:11:03.000Z

Do you mean working directories for a Session in Code? If so...

I deleted the directory for a Session and when I opened up Claude, it takes a few seconds and maybe switching between recent sessions before it gave me a prompt for a Session that had the working directory removed: "Working folder no longer exists. Choose a different folder to continue." with options to "Choose folder" or "Archive". After choosing a new folder, it worked as expected.

The old directory choice is still available in the New Session dialog when selecting the latest working directory, but if you leave that open for a few seconds, the "invalid" directories disappear. There's definitely something going on in the background, but it's slow.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Simplest recovery: make the old path exist again, instead of editing config

That only stops the error, it does not allow you to then remove that entry as a known dir in the desktop app, meaning _you can never remove that dir anymore_, so that's not a solution, that's a temporary hack at best.

You're right, and thanks for the correction. What I posted gets the app to start again; it does not get rid of the entry. Calling it a recovery was fair, calling it a solution was not.

Two things that look like they actually remove it.

In-app (reported in this thread, not something I've reproduced): @alex-friant described a newer Desktop build showing "Working folder no longer exists. Choose a different folder to continue." with Choose folder and Archive buttons — Archive being the one that drops the session instead of repointing it. They also noted that the invalid entries disappear from the New Session dialog on their own if you leave it open for a few seconds.

On disk — and one correction worth flagging, because following this issue's workaround today can send you to the wrong place. The paths in the original report are under %APPDATA%\Antigravity\.... On a current Windows install (checked 2026-09-16) the session state lives under:

%APPDATA%\Claude\claude-code-sessions\<account-id>\<workspace-id>\local_<session-id>.json

Each of those records carries cwd, originCwd, and a boolean isArchived. So the stale directory is attached to session records that still point at the dead path — not to a separate "known directories" setting with no way to reach it. That's the part of "you can never remove that dir anymore" that I think is recoverable: archive or remove the sessions bound to that path and the entry has nothing left to hang on.

Limits, so nobody takes this further than it goes: I'm not a maintainer; I verified the file layout and the field names, but I did not reproduce the delete-then-recover flow, and I did not inspect the app's Local Storage / IndexedDB, so I can't rule out another cached copy of that list. Back up the folder before editing anything, and prefer the in-app Archive if your build offers it.

I'm on the latest desktop app, and unfortunately it does not detect folders that are gone, it will still get stuck =(

The only solution I've found is to remove the binding from the desktop app itself, meaning taking it out of the git worktree, as well as then fixing all sessions, but the sessions do not live where you say they do - at least not for me. Claude Desktop installs as a "windows store" app instead of a normal application, and ens up in %LOCALAPPDATA%\Packages\Claude_randomHashHere\LocalCache\Roaming\Claude (amazing, let's put the roaming profile in appdata\local instead of appdata\roaming, let's just vibe code this desktop client why not).

So I had to edit <that dir>\git-worktrees.json to make sure the list of current working directories only contained the ones that should actually be used, and then I had to edit <that dir>\claude-code-sessions\<uuid>\<uuid>\local_<uuid>.json to rewrite the non-existent dir entry to one of the cwd entries in the worktrees configuration.