Cannot remove/change primary working directory, and stale folder paths are unrecoverable

That's is existing limitation that confuses in the very beginning of work. Additionally, it consumes tokens for nothing as the Claude code looks in inactive projects
I have it on Windows Claude code

The "working directory no longer exists" failure here is downstream of the same design: absolute path as the project key, with no re-link path.
I've written up a consolidated design proposal on #48394 — a staged, path-independent project identity (workspace.json UUID, git-remote fallback, auto re-bind on move) plus a claude project relink command that would directly address the unrecoverable-stale-path case here.
Linking since this is still open — consolidating these duplicates under one tracking issue would help. 👍 if you're still hitting this.
Related: #33634 (closed/locked), #41344 (closed as dup), #48394.

I have the exact same issue, and it sticks the old stale project directory on my plugins as well

Adding another concrete use case, because this is bigger than it looks.

I reorganized my top-level projects directory on my own machine — grouping existing folders under new software/ and media/ parents, a routine cleanup. The result: every Cowork project and chat that had a folder assigned broke at once. Folders show empty or throw "Working directory no longer exists," and there's no way to point them at the new location. For the primary working directory there's no way to change or remove it at all.

The root cause, as others note above, is that projects are keyed to an absolute path with no re-link path. Editing the stored config on disk doesn't help — the binding isn't re-read on reload — and the only "fix" offered is to re-add the folder as a new project, which discards the conversation history and memory that are the entire reason to use a project.

It is genuinely unreasonable that reorganizing folders on my own computer destroys my Cowork context. Please prioritize the path-independent project identity + relink proposal in #48394 (match by a stored ID / git remote, auto re-bind on move), and at minimum let users update a stale primary working directory instead of leaving the session permanently broken. Renaming or moving a folder should never be a destructive, unrecoverable action.

Reproduced this on Windows 11 too, with a specific variant worth noting: after the "Working folder no longer exists" prompt, selecting the new (correct, existing) folder location fails with "Couldn't fork this session" — so the app does attempt some kind of recovery/fork mechanism here, it just fails partway through, rather than never trying.

Repro: renamed a project folder via git mv (external to the app), then tried resuming a session tied to the old path. Failed consistently across multiple retries, including after fully killing the app process and relaunching.

One data point that might help others worried about this: the underlying data is not lost — the session .jsonl transcripts correctly exist on disk under the new path's project storage (~/.claude/projects/<new-path>/), confirmed directly. This really does look like purely an app-side resume/fork bug on top of otherwise-intact data, consistent with what's already been said above about the stored-absolute-path root cause.