Desktop app: cannot change primary working directory or open new chat

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/53496
2. https://github.com/anthropics/claude-code/issues/49888
3. https://github.com/anthropics/claude-code/issues/51655

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

This feels like workspace-authority plus session-liveness failure at the same time.

If the desktop app cannot change the primary working directory or open a new chat, then two core recovery paths are gone together:

• users cannot re-anchor the session to the right operational world
• users cannot escape into a fresh session when the current one is compromised

That makes the app feel trapped inside a stale or broken state with no clean route back to control.

I would want clarity on:

1. whether working-directory switching is blocked by UI state, backend session state, or filesystem/path validation
2. whether the inability to open a new chat is causally related to the same stuck state or a separate failure
3. whether the product can surface which session/workspace is currently authoritative when those controls stop responding

When both re-rooting and fresh-session creation fail, the operator loses the two simplest ways to recover from environment drift. That turns an ordinary bug into a control-surface reliability problem.

Having this issue as well. I attempted to migrate my project location today and the desktop app will not stop trying to point to the old location even after deleting the files there

Confirming this bug — Windows 11, still broken, blocking all desktop app use for Claude Code

Adding my report to raise visibility, as this has made the desktop app unusable for me for over two weeks.

Environment

• OS: Windows 11 Pro
• Claude Code desktop app (not CLI): version 1.7196.1 (ddbeb7)
• Subscription: Max 5x ($100/month)

What's broken

• Clicking "+ New Session" / "New Chat" does nothing — no dialog, no new session, no error. Completely unresponsive.
• The New Session button displays a macOS Command glyph (⌘) instead of the Windows Ctrl shortcut hint (related: #48115). Ctrl+N also does not create a session.
• This has been happening consistently for 2+ weeks across app restarts and updates.

Impact
I'm a paying Max 5x subscriber and Claude Code on the desktop app is a primary reason I subscribe. I specifically prefer the desktop experience over the CLI. Right now I cannot start a new session in the desktop app at all, which means the product I'm paying for is effectively unusable for my main workflow. I've tried the in-app help and other channels with no resolution.

Request
This affects multiple users across several open issues (#54461, #50388, #49850, #31943). Could this please be prioritized, and is there an ETA or official workaround for the desktop app specifically (not "use the CLI instead")? Happy to provide logs or test a fix.

I am having a similar problem. when opening claude code session in claude desktop app (which I much prefer, let alone because text is not in monospace typeface), it always opens in the first repository folder I was working in. so each session has access to that very folder, which does not only send way to much context along but is also just wrecked.
I tried deleting memory files, tried to work with some settings.json. no success at all!

Windows workarounds for the pinned Working Folder

Quickest — open any folder as a new Code session directly. The Desktop app registers a claude:// URL protocol. Firing this opens a fresh session in whatever folder you specify, even while the app is running:
claude://code/new?folder=C:\path\to\your\folder
Run it via Win+R, a browser address bar, or a desktop shortcut. If your path has spaces and it doesn't open, URL-encode them as %20 (e.g. My%20Projects).

Note on how the folder actually sticks: the deep link opens a new, unsaved session pointed at your folder. It's only committed when you send your first prompt — that's the moment the folder is saved to that session. Until then it's provisional: if you click an existing session before sending that prompt, the app reverts to the old pinned folder and you'll have to run the command again.
Once you've sent a prompt and the session is saved, keep it in the sidebar and set the sidebar sort to by project. A + then appears next to the project name — from there you can start new sessions in that folder directly from the sidebar, no deep link needed.

If the app is fully stuck on a pinned/broken folder — reset Local Storage.
⚠️ This clears all of the app's Local Storage, not just the pinned folder: you may be logged out and lose some settings, and the session list disappears from the side panel. Transcript files on disk are untouched (C:\Users\<username>\.claude\projects\), but the UI stops indexing them.

1. Fully quit the Claude Desktop app.
2. Delete the contents of the leveldb folder (not the folder itself): C:\Users\<username>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\Local Storage\leveldb (path may differ on older standalone builds)
3. Reopen — the Code tab has no pinned project; pin your desired folder fresh.

If you'd rather not type the deep link each time or delete your app's Local Storage:
I made a small portable launcher with a folder picker and recents that wraps it: open-in-claude

https://github.com/user-attachments/assets/97b61346-a72c-467a-98a8-6d9d031ac7bc

You can't change directory mid session.
To start a new session in another working directory:

• Create a new session
• Click on the working directory at the bottom of the screen
• Select the new working directory.

Thanks @AimenKhalidArbisoft ! Worked for me

Same on Windows 11, Claude Code 2.1.186 (Desktop). Adding a common trigger and a data point:

A pinned session whose original working directory lived on an external/removable drive hard-errors on every message once that drive is unmounted:

Working directory no longer exists: D:\...\<project>. The folder may have been moved, deleted, or unmounted.

There is no GUI path to repoint the session at a new folder, so the whole conversation is bricked — even though the transcript is fully intact under ~/.claude/projects/. The only escape is claude --resume <id> from a terminal in a valid folder. This is exactly what #69902 asks for: on resume, detect the missing cwd, prompt for a recovery directory, and update it instead of hard-failing. A "change working directory" control in the Desktop UI (and honoring /cd) would cover both this and the "primary directory is permanently pinned" half of this issue.

Confirmed today on Windows 11 x64 running the latest Claude Desktop available (literally just updated a few minutes ago).

/cd doesn't work (says can't run in this environment whatever that means)
Clicking the path up top only lets me see it not change it
No options anywhere to change the working directory.

1 Working work-around: After creating a proper HANDOFF file I started a new session. *Although this session still forced itself into my previous working directory I was able to click the working directory name (directly above the chat pane) and it let me change it!! This *only works for a brand new naked session tho.. once you've done anything then that same thing I clicked on is now locked down to View-Not-Change.

1) Create new session should *Always ask where to root itself. I almost never want to re-use an old session.
2) You should *Always be able to re-home a session. That should never be disabled.

Having the same issue. And I can't X the older folder. I can only add new folder which clutters the view of a new session. If a project is old and irrelevant, I shouldn't see on the new session every time.
Plus, this not only affects the UI but also it opens the wrong folder I click "open in finder/cursor", which makes it so annoying to edit a file or run a command in the terminal for that specific project.

I want to document the full user journey that led me here, and add a specific data point that hasn't been covered yet.

What I was trying to do: open a project in a specific folder from the Claude Code desktop app. A basic operation any multi-project user needs.

---

Step 1: tried the obvious paths in the app — all blocked

• Clicked "New Conversation" → no folder picker, session opens in a fixed default directory
• Typed /cd G:\path\to\project in the chat → "/cd isn't available in this environment."
• Clicked the directory label at the top of the session → read-only, cannot change it

Bug confirmation: /cd is explicitly blocked in the desktop app on v2.1.191 (Windows 11, latest as of June 2026). /cd was introduced in v2.1.169 and works correctly in CLI on the same machine. This is not a version issue — it is being explicitly disabled in the desktop app context.

| Method | CLI | Desktop App |
|---|---|---|
| Folder picker on "New Conversation" | N/A | Does not exist |
| /cd command | Works | Blocked |
| Launch claude from terminal in target dir | Works | Session not surfaced in sidebar |

---

Step 2: tried the CLI workaround — sessions don't sync to the app

Opened PowerShell in the target directory, ran claude. Session was saved to ~/.claude/projects/ but never appeared in the desktop app sidebar. Restarting the app did not help.

---

Step 3: found this issue and the existing workarounds

I found @LordRasa's claude://code/new?folder= protocol and the open-in-claude launcher. I found @omnipitous's observation that a brand-new session allows clicking the directory label once before locking. I found @wherewolf87's request to honor /cd.

These are all valid. But they all share the same problem: they require the user to know they exist. They are buried in GitHub issue comments. Zero percent of non-technical users will find them.

---

Step 4: the claude:// protocol already solves this — the app just needs to wire it up

Using claude://code/new?folder= I implemented a Windows right-click context menu via registry, confirmed working:

HKLM\SOFTWARE\Classes\Directory\shell\OpenInClaudeCode\command
→ powershell.exe -WindowStyle Hidden -Command "Start-Process ("claude://code/new?folder=" + "%V")"

This required: finding the protocol in a GitHub comment, writing registry entries manually, running PowerShell as administrator, restarting Explorer.

The point is not that this works. The point is that the app already has everything it needs to do this automatically:

• claude://code/new?folder= protocol exists and works
• The installer just needs to register the right-click context menu on install — the same way VS Code and Git do, with an opt-in checkbox
• "New Conversation" just needs a folder icon that calls claude://code/new?folder=<picker result> — no new engineering required

The infrastructure is there. This is purely a packaging and UI decision that was not made when the desktop app shipped. Users should not have to dig through GitHub issues and write registry entries to do something the installer could have handled in one checkbox.

---

What should ship:

1. Installer registers right-click context menu — opt-in checkbox, same pattern as VS Code and Git
2. "New Conversation" includes a folder picker — calls the existing claude:// protocol internally
3. /cd enabled in the desktop app — already works in CLI, no reason to block it in the app
4. CLI sessions surfaced in the desktop app sidebar — sessions written to ~/.claude/projects/ should be visible regardless of entry point

---

Related issues closed as bot-detected duplicates without resolution

• #36175 — Desktop app: no folder picker (auto-closed, locked)
• #56038 — CLI↔Desktop session sync (auto-closed as duplicate of #28791, which remains open)
• #60151 — Allow switching working directory at runtime (auto-closed as duplicate)

None of these were resolved. The bot closure creates a false impression of progress.

+1, same problem on MacOS. All new Claude code sessions are pinned to the same directory.

Update on my May 17 report: this has been fixed for me for a while now — I believe sometime in mid-June. I can change the working directory and open new chats normally on Windows 11 (Claude Code desktop app, current version). No longer able to reproduce, so this may now be limited to macOS or specific setups. Leaving my original report above for history.

+1, same problem on MacOS. All new Claude code sessions are pinned to the same directory.

I do note that my "Recents" has several projects with different working directories. It so happens that one of them is the one I want to continue working on. If I select that one and THEN click "+ new session" it seems to attach to the desired working directory.

Same issue here as of today. Amazing that it is open so long and is a significant usability issue.

Confirming this bug + root cause and manual fix
Environment: Windows 11, Claude Desktop 1.20186.1.0 (MSIX package), Claude Code 2.1.205
How I hit it: I asked Claude in a chat (claude.ai) to create a project for a future website. This spawned a Code session pointed at a folder that was never actually created on disk (...\Code\[projectname]). That path became the pinned primary working directory in the desktop app's Code tab and could not be changed or removed from the UI.
What did NOT fix it:

Deleting the folder from disk + full app restart (app still showed the pin and threw "working directory no longer exists" errors)
Archiving sessions — no local or cloud sessions referenced the folder
Uninstalling the MSIX version and doing a clean install of the standard .exe desktop app — the pin survived the reinstall

Root cause: The pinned path is stored as a project entry in the shared config at ~/.claude.json under the "projects" key. Because both the desktop app and CLI read this file, and it lives outside the app's own data, it persists across folder deletion, restarts, and reinstalls.
Manual fix that worked:

Fully quit Claude (all processes)
Back up ~/.claude.json
Remove the projects entry keyed to the phantom path
Relaunch — the app then showed a normal "Trust this workspace?" prompt for the stale path; clicking Cancel released the pin and restored the normal folder picker

Suggested fixes: (a) give the folder chip a way to change/remove the primary directory in the UI, (b) validate that a projects path exists on disk before pinning it as the default, and (c) don't let chat-spawned Code sessions register a project for a directory that was never created.

Setup: macOS, Desktop app version Claude 1.21459.0 (f7518f) 2026-07-14T05:32:17.000Z, CLI 2.1.210 (separate native install).

What happened:

I had an existing project (project-alpha) with a few sessions already going. Tried to spin up something totally unrelated (project-beta) from the Code tab.

• Hit New session. The folder chip at the bottom was already pre-filled with project-alpha, not blank.
• Clicked it and added project-beta. It just got tacked on as a second folder instead of replacing the first.
• The new folder got an × to remove it. project-alpha didn't get one, so there's no way to pull it out.
• Asked the session what directory it was actually in. Answer: still project-alpha, CLAUDE.md and all, even though project-beta was sitting right there in the chip list.

So adding a folder doesn't make it primary. It just rides along.

Workaround, and its limits:

Launched the CLI straight from Terminal (cd project-beta && claude). That rooted correctly, no issues. But that session never shows up in the Desktop app's sidebar, even after a restart, so you lose the GUI stuff (diff view, file panel) for anything started that way.

Also checked ~/.claude.json to see if the pin could just be edited out. No dice: it only stores trust settings per folder, nothing marking one as "primary." Matches what @mainessr found above.

Bottom line:

The picker isn't missing, like some other reports here. It's actually worse, because it looks like it worked. You pick a new folder, it shows up in the chip list, everything looks fine, and then your first message still gets rooted in the old project with zero warning. Adding a real "remove/replace primary" control on that chip would fix it.

The other behaviour if you are running multiple projects and so multiple sessions at the same time is that Claude Code will silently jump into the original Repo folder, so you are working on Project X and the original folder when you first installed Claude Desktop was Project A it silently jumps to Project A from Project X. I now have specific instructions in my Claude.md file stating the repository and every new session has to read and confirm the Repo before it starts.

This is a sample of what I now need to do as part of a start prompt for a session.

1. Prefix every XXXX shell command with cd /c/XXXX && explicitly — git, pytest, ruff, mypy, all of it. Never rely on a prior cd having stuck.
2. If any command's output looks unexpected (wrong commit hash, wrong file list, wrong test count), that's the tell the cwd silently reset — stop and re-run cd /c/XXXX && pwd && git rev-parse --show-toplevel before trusting anything further.
3. Now continue: cd /c/XXXX && git status -sb && git log -1 --oneline to confirm HEAD is ******** on origin/main with a clean tree....

@ejd1103

Hit New session. The folder chip at the bottom was already pre-filled with project-alpha, not blank. Clicked it and added project-beta. It just got tacked on as a second folder instead of replacing the first. The new folder got an × to remove it. project-alpha didn't get one, so there's no way to pull it out. Asked the session what directory it was actually in. Answer: still project-alpha, CLAUDE.md and all, even though project-beta was sitting right there in the chip list. So adding a folder doesn't make it primary. It just rides along.

Since this issue was fixed (or at least partially fixed) a lil while ago I'm pretty sure you clicked the wrong folder button? I can't be 100% sure since you're on Mac and I'm on the Windows version but for your reference:

When you start a new Session:

• YES it will default to your last session folder (We would all prefer a folder picker instead but for now that's what it is)
• BUT: The First thing you do (emphasizing since this option goes away if you do anything else) Is click on the Selected Folder NOT the "Add Folder" button/icon. (Literally clicking on the old folder name).
• When you do that it will give you a different mini picker where you can either choose another previous folder or there's an "Open Folder" button that will let you browse for a net new one.
• Voila your *primary working folder is now the one you pick not "added on".. it's "replaced"

I've done this for a number of projects now and it's been working since they released the patch 3 weeks ago.