[BUG] New Cowork sessions inherit working folder from prior in-memory session (affects both UI "+ New" and claude://cowork/new deeplinks)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Summary
When Claude Desktop is already running with an active Cowork session, creating a new Cowork session — whether via the in-app "+ New" button or a claude://cowork/new deeplink — results in the new session inheriting the working folder from the prior session. For deeplinks that pass a folder param, the new session ends up with both the inherited folder and the deeplink's folder attached, rather than only the deeplink's folder. The behavior does not occur on a fresh app launch
Why this is a bug
Documented contract for /new (and the user mental model for "+ New") is a fresh session.
The deeplink's folder parameter is documented in the singular ("adopted as the working directory"), implying authoritative replacement, not additive merge.
UX impact: Confusing for users clicking "+ New" who don't expect prior folders to carry over. Particularly problematic for "Open in Claude Cowork" buttons in third-party tools, where the caller has no visibility into prior session state and cannot reason about what will be attached.
Safety impact: A folder the user intended to scope out of a session remains in scope, expanding the blast radius of any prompt run there. Especially relevant given Cowork's agentic nature and file-write capabilities.
Reference
https://support.claude.com/en/articles/14729294-open-claude-desktop-with-a-link
What Should Happen?
When Claude Desktop is already running with an active Cowork session, creating a new Cowork session —
- via the in-app "+ New" button : Should create a new session without a working folder set
- claude://cowork/new deeplink: Should result in a new session with working folder only set to parameters passed in the deep link
Error Messages/Logs
Steps to Reproduce
Steps to reproduce — deeplink path
- Launch Claude Desktop.
- Fire claude://cowork/new?q=Draft the Q2 update&folder=/Users/me/docs → session opens with /Users/me/docs. ✅
- Without quitting the app, fire claude://cowork/new?q=Draft the Q2 update&folder=/Users/me/downloads.
- Actual: new session has both /Users/me/downloads and /Users/me/docs attached.
- Expected: new session has only /Users/me/downloads attached.
Steps to reproduce — UI path
- Launch Claude Desktop.
- Open a Cowork session with /Users/me/docs as the working folder.
- Click "+ New" to create a new Cowork session. Do not manually add any folder.
- Actual: new session has /Users/me/docs pre-attached.
- Expected: new session has an empty working directory.
Isolating tests run
Test A — fresh app launch: Fully quit, relaunch, fire deeplink as the first action → only the deeplink's folder is attached. ✅ Rules out persisted state and confirms the carryover lives in in-memory session state.
Test B — UI "+ New": Creating a new session via the UI button reproduces the carryover → bug is at the session-creation layer, not deeplink-specific.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude 1.4758.0 (fb266c) 2026-04-24T20:22:30.000Z
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
3 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is a meaningful scoping bug, not just a UI annoyance.
A new Cowork session inheriting the previous working folder breaks the user’s core expectation that session creation resets authority boundaries. In an agentic environment, attached folders are not cosmetic state; they define what data is in scope for search, read, diff, and write operations.
That makes the deeplink case especially important. A third-party tool generating
claude://cowork/new?folder=...is trying to establish an explicit scope contract. If Claude merges prior in-memory folders into that new session, the caller’s requested boundary is no longer authoritative and the user can unknowingly operate with a wider filesystem scope than intended.So I would frame this as a context-isolation failure at session creation.
+ Newand deeplink-driven new sessions should start from an empty authority set unless the new invocation explicitly supplies replacement scope.This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.