Working Directory Misreported; CLAUDE.md Not Auto-Loaded

[yowshi]

Summary

When switching from Chat mode back to Cowork mode, the previously selected working folder is shown as still active (cached from the prior session). However, the underlying virtualized mount path from that session (e.g., /sessions/<session-id>/mnt/rcdsktrials/) no longer exists in the new session. Claude reports the folder as correctly set, but file operations fail because the path is stale. Additionally, because the working directory is not correctly resolved, any CLAUDE.md present in the selected folder is never auto-loaded, silently bypassing any user-defined rules it contains.

Environment

• Application: Cowork (Claude desktop app, Cowork mode)
• Underlying framework: Claude Code / Claude Agent SDK
• OS: Debian GNU/Linux 12 (Bookworm)
• Desktop Environment: KDE Plasma (X11)

Steps to Reproduce

1. Use Cowork with a selected folder (e.g., ~/Documents/rcdsktrials/) in one session
2. Switch to Chat mode, then switch back to Cowork mode
3. Observe that the previous folder is shown as still selected — do not manually re-select it
4. Ask Claude what folder it is working in
5. Claude confirms the folder name (e.g., "rcdsktrials") without flagging any issue
6. Ask Claude to list files or read a file from that folder
7. Observe that Claude fails — the virtualized mount path from the previous session no longer exists

Expected Behavior

• The working directory should resolve correctly to the actual system path of the selected folder
• CLAUDE.md present in the selected folder should be automatically read at session start, before any user interaction, consistent with how Claude Code handles memory files
• Claude should not confirm a working directory without verifying the path is actually accessible

Actual Behavior

• Claude reports a virtualized path (/sessions/<id>/mnt/<folder>/) as the working directory
• That path does not exist or is empty, causing all file operations to fail
• CLAUDE.md in the selected folder is never loaded, so any user-defined rules or instructions it contains are silently ignored for the entire session
• Claude accepted and confirmed the misreported path without performing any sanity check

Impact

• User-defined rules in CLAUDE.md (e.g., confirmation requirements before running commands, file operation restrictions) are bypassed entirely — not intentionally, but because they are never seen
• This is a significant trust and safety issue: users may rely on CLAUDE.md to enforce guardrails, and those guardrails silently fail to load
• File read/write operations fail unexpectedly, causing confusion

Workaround

Users can place their CLAUDE.md content in ~/.claude/CLAUDE.md (the global user-level memory file), which is loaded reliably regardless of the working directory. This is not ideal for folder-specific rules but serves as a reliable fallback until the working directory resolution is fixed.

Suggested Fix

1. When a folder is selected in Cowork, resolve and verify the actual system path before reporting it as the working directory
2. Auto-load CLAUDE.md from the verified path at session start, before the first user message is processed
3. If the path cannot be verified or resolved, surface an error to the user rather than silently proceeding with a broken working directory

[github-actions]

I have enough context from the classification data to write the comment. Let me draft it now.

---

The stale path problem is the root cause here. When you exit a Cowork session and re-enter, the VM session ID changes, but the old mount path (/sessions/<old-id>/mnt/<folder>/) gets cached and reported as the working directory. The path doesn't exist anymore. CLAUDE.md not loading is a downstream effect of that — the app looks for it relative to the working directory, finds nothing, and silently skips it.

This lives in Cowork's session lifecycle management on the upstream side. The VM session teardown isn't clearing the cached path before a new session starts. Patching it here would mean intercepting the working directory resolution in the JS layer — possible in theory, since we already patch BrowserWindow behavior via frame-fix-wrapper.js — but Cowork's session state is managed server-side, so we'd only be able to mask the symptom, not fix the root cause.

The most practical path forward is an upstream fix. The session manager needs to invalidate cached mount paths when a session ends. If you can reproduce this consistently, filing a report with Anthropic support is the right move. Include the stale path you're seeing and the session IDs if they're accessible from the app.

---

Written by Claude Sonnet via Claude Code