[FEATURE REQUEST] Cowork: Set a default project folder that auto-loads on session start

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/27514
2. https://github.com/anthropics/claude-code/issues/34604

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

Still hitting this every session — no workaround exists
Quick update after a couple of weeks living with this. I've tried every angle I can find:

Global CLAUDE.md — Added a strong "BEFORE doing anything else" blocker instruction telling Claude to check for the mounted folder. It helps, but Claude still skips it sometimes (instruction-following inconsistency, not a technical bug).
Cowork Settings instructions field — Added a second layer there. Fires earlier in the session than CLAUDE.md, but still can't trigger an actual mount.
Config files — Checked claude_desktop_config.json and every other config location I could find. There's no defaultWorkspaceFolder key or anything similar.

Bottom line: There is no workaround. Every single Cowork session starts with a manual folder selection. If I forget (easy to do), the first few tool calls either fail or target a temp directory. Scheduled tasks are also affected — they can't reliably assume the workspace is available.

I see this has been flagged for auto-closure as a duplicate of #27514 and #34604. Both of those were closed as "not planned" due to inactivity — not because the feature was rejected or delivered. Closing this as a duplicate of a dead issue just buries the request. If there's a better place to track this, I'm happy to move the conversation there, but this is still a real gap with no workaround.

I NEED this to be implemented. About to deploy Claude Enterprise to ~250 users in a Windows environment, and as a mostly non-technical audience they are most excited about Cowork. This crowd will absolutely forget to select a folder and assume the app is broken the the doc it generated lands in a folder that doesn't exist

+1 — hit a concrete data-corruption-ish symptom directly traceable to the Documents default on Windows.

Symptom: Cowork's Edit tool silently rejected writes to one specific existing file in a workspace placed under C:\Users\<user>\Documents\Claude\Projects\atom vpn automation\ (the default location). Write on a new file in the same folder succeeded. The pattern was reproducible across the session — we ended up generating a .patched sibling and doing Copy-Item -Force from PowerShell as a workaround for every change.

Root-cause diagnosis (after running Get-ItemProperty on the OneDrive registry, Get-MpPreference, Get-Item Attributes, Get-Process SearchIndexer, and reviewing the Windows Indexing Options GUI):

• OneDrive KFM: not applicable (Documents not redirected)
• Files On-Demand placeholder: ruled out (Attributes = Archive only)
• Controlled Folder Access: disabled
• Windows Search Indexer: actively running, with the Users folder in scope and only AppData excluded — meaning Documents\Claude\Projects\... is being indexed continuously
• Folder name with spaces (atom vpn automation) likely compounds the issue at the 9P mount layer

The combination of (a) the indexer holding transient handles on .py files and (b) the Edit tool's temp-write→rename pattern on a path with spaces produces the silent failure. Moving the workspace to C:\dev\atom-vpn-automation\ would have avoided it entirely.

Concrete asks:

1. The setting proposed in this issue (and in the duplicate-closed #34604) — cowork.defaultWorkspaceFolder in claude_desktop_config.json
2. Even better: change the dialog pre-fill default from ~/Documents/Claude/Projects to a platform-appropriate, non-indexed, non-OneDrive-tracked location on Windows (e.g., %USERPROFILE%\Claude\Projects or %LOCALAPPDATA%\Claude\Projects)
3. In-dialog warning if the chosen path is in Documents/OneDrive/iCloud, given how frequently this default produces silent file-write failures

Environment: Windows 10 (Korean UI), Claude Desktop (latest as of May 2026), Defender RTP on, no third-party AV, Documents indexed by Windows Search.

Related: I just filed #57907 about a separate cosmetic bug where the same dialog shows mixed path separators (C:\Users\<user>\Documents/Claude/Projects).

from an end user perspective, it would be nice to have a configuration that allows me to have another default location for potentially large amounts of files to be saved, instead of my small system dir.

+1 here as a nontechnical end user trying to adopt Claude Cowork, the default folder is really annoying to do every time I open a new session. In particulat, the default path for me is C:Users/[name]/AppData/Roaming/Claude/[local-agent-mode-sessions]/[UUID]/[UUID]/[UUID]/outputs and the three layers of GUIDs are causing me trouble with filepaths being too long, essentially impossible to find manually, and Windows Explorer hides the path by default. So if I do forget to mount the right folder I functionally NEED Claude to send me the direct filepath link, which can easily get lost between sessions.

Confirming this on macOS too — it's not Windows-specific, so the platform:windows label probably undersells the scope.

My setup: a Cowork Project with a workspace folder explicitly set. New sessions still don't mount that folder — they fall back to the internal ~/…/local-agent-mode-sessions/<session-id>/outputs path. So even the Project-level workspace folder, which is supposed to be the persistence mechanism, doesn't reliably carry across sessions. This looks related to #51513, where the project's "On your computer" entry goes stale and points at an already-cleaned session-cache path.

One downstream consequence worth calling out: this breaks session-start instruction files. Because the folder isn't mounted at start, Claude can't read it — a circular dependency where the file meant to bootstrap the session lives in the folder the session failed to connect to. The only reliable workaround I've found is mounting the folder through a filesystem MCP server instead, which somewhat defeats the purpose of the built-in folder/project feature.

Strong +1 on the proposed solutions. Ranked by impact:

1. A Project-level workspace folder that actually persists and auto-mounts at session start — arguably this should already be the default behavior.
2. A global "default output folder" setting as the fallback for non-project sessions.
3. At minimum, the suggested fallback: prompt to reconnect the last-used folder rather than silently writing to an internal path.

The silent fallback is the worst part — files land somewhere unexpected and can get cleaned up before they're retrieved.

Adding a data point that changes the shape of this request, because the setting being asked for here partly exists already. I had BriBot trace the behavior on my own machine; the findings below are its work.

On macOS, a persistent default folder for new project-less Cowork tasks is already stored and already honored. It is not in claude_desktop_config.json and not in cowork_settings.json, which on my machine is an empty object. It lives in the renderer's localStorage for the claude.ai origin, in:

~/Library/Application Support/Claude/Local Storage/leveldb/

The leveldb block is snappy-compressed, so the key name is not fully recoverable, but the surviving literals read default- and target, and they sort between cowork-browser* and cowork-image-names*. The value is legible in full:

{"kind":"...","path":"/Users/<me>/Local Docs/11.BriBot Output"}

That is a scalar object with a single path. A Cowork project's folder list, by contrast, is a real array - one of mine carries four folders. So the two code paths that mount folders use two different data shapes, and the one behind the + New button is structurally limited to exactly one folder.

The practical consequence, in my case: + New opens a task with my output folder mounted and my main working vault absent. Both folders are already on localAgentModeTrustedFolders, so permission is not the obstacle. Trust and mount are separate mechanisms, and having the folder on the trust list makes the missing mount look like a permissions bug when it is not. That distinction cost BriBot and me several rounds of investigation before we found it.

Two asks, in priority order:

1. Make the new-task default an array, using the same shape a project's folders list already uses. This is the substantive fix, and it is a smaller change than building the feature from scratch, since the storage and the honoring logic both already work.
2. Expose it in the user interface (UI), in Settings under Cowork, next to Folder Permissions. Right now the value is written by some implicit last-used rule and there is no way to read it, set it, or clear it. A user who wants to change which folder + New opens with has no way to do so short of editing a compressed leveldb file.

One note for anyone else trying to diagnose this locally: BriBot also checked app.asar, and the string default-target does not appear anywhere in it, because the Cowork UI is served from claude.ai rather than bundled with the desktop app. Nothing about this is patchable on the user's machine.

Environment: macOS, Claude Desktop, August 2026.