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

[jacksonkelly01]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

You're right, my mistake. Here's what to paste into each field:

Two issues with folder management in the desktop app: (1) When creating a new chat, a folder is already attached as the primary working directory and there's no way to remove it. I can only add more folders. The session gets named after the unwanted folder. (2) I moved a project folder on disk and the session that referenced it is now permanently broken — it errors with "Working directory no longer exists" and there's no way to update the path.

What Should Happen?

I should be able to remove or change the primary working directory when creating a session. Sessions with stale folder paths should let me update the path instead of being unusable.

Error Messages/Logs

Working directory no longer exists: /Users/jacksonkelly/Desktop/ai/claude/claude code/personal tools/build my plate. The folder may have been moved, deleted, or unmounted.

Steps to Reproduce

Move a project folder to a new location on disk
Open the session that referenced that folder
Try to add the folder at its new location — get the error above
For the other issue:

Create a new chat — a folder is pre-attached
Try to remove it — there's no option to

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

1.10628.2

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[microbidsoftware]

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

[idx]

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.

[epicgm]

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

[dougdaulton]

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.

[theryanhome]

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.