[FEATURE] Expose configurable memory and CLAUDE.md paths in Cowork mode

[Wolfgangs246]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Cowork mode inherits Claude Code's auto-memory system and CLAUDE.md loading, but neither path is user-configurable within Cowork's UI.

Memory path: Auto-memory writes to a hardcoded local VM path. Users working from multiple devices (desktop and laptop) cannot share memory state between them, and the built-in persistence layer is opaque — users can't browse, manage, or co-locate memory files alongside their other project documents.

CLAUDE.md path: Users can work around this today by mounting a cloud drive and adding a read instruction to a local CLAUDE.md that points to the cloud-hosted copy. But this is a workaround, not a supported configuration. The local CLAUDE.md becomes a bootstrapping shim rather than the actual instructions file.

Context: Claude Code (CLI) already has infrastructure for configurable memory paths — CLAUDE_CODE_AUTO_MEMORY_PATH (v2.1.64) and autoMemoryDirectory (v2.1.74). These address the same need but are not exposed to Cowork users. Cowork's sandboxed VM environment doesn't surface environment variables or a settings.json for user configuration. Existing feature requests (#28276, #1292, #25739) cover the CLI side — this request is specifically about the Cowork product surface.

Use case: I run multi-project design work through Cowork with all structural documents (project briefs, design files, backlogs) hosted on Google Drive. The startup protocol mounts the drive and loads project files from it every session. This works reliably for CLAUDE.md (via a local shim) and all project documents — but memory files are the one piece of session continuity that can't be co-located with everything else. Making both paths configurable would deliver cross-device access, a single source of truth, and user visibility over memory files.

Proposed Solution

Expose the existing autoMemoryDirectory setting and an equivalent CLAUDE.md location setting within Cowork's configuration surface — whether that's a settings panel in the Claude desktop app, a project-level config option, or a property within the CLAUDE.md file itself.

The underlying infrastructure already exists in Claude Code (CLI). The ask is specifically about surfacing these options in Cowork mode, where users don't have access to environment variables, settings.json, or CLI flags.

Related CLI-side issues: #28276 (configurable memory), #1292 (configurable CLAUDE.md), #25739 (portable memory across machines). This request covers the same need from the Cowork product surface, which has no current mechanism to set these paths.

Alternative Solutions

No response

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

I would like a persistent experience whilst toggling between using my PC version and Laptop versions of Claude CoWork.
Whilst I may use either as a VM environment for discussion and instruction, I would like a consistent location for Claude instructions to exist without having to rely on Global instruction dialogues which Claude Cowork has managed to self-rationalize itself around.
This solution would effectively allow me (and potentially others) to maintain a persistent working document repository without synching issues.

Additional Context

No response

[github-actions]

Found 3 possible duplicate issues:

1. [FEATURE] Configurable auto-memory storage location (memoryDirectory setting) #28276
2. [FEATURE] Portable project memory across machines (multi-device workflow) #25739
3. Feature Request: Allow project-scoped memory to be stored inside the repository for cross-device sync #38519

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

[Wolfgangs246]

The links referenced focus on the Claude Code environment and not the CoWork environment. This is a feature request for Claude CoWork.

[matthewadams]

I agree. My use case would be to share cowork task state as files, and put those directories under git source control. That way, I get not only sharing across devices, but also versioning, branching, etc. I haven't thought it through, but there could be room for cowork to include git features, like being able to specify the git repo and possibly path relative to the repo root for task file storage. Just having all files in one location within a task would be sufficient, as @Wolfgangs246 is requesting; I can handle the git aspect of it manually.

[NicoleSchwartz]

I agree, I am also using GitHub as a way to backup, and share, many of my project files and skills I create and have been frustrated and being unable to set a specific folder to automatically be mounted at the start of each task

[tkgally]

+1 on this. My use case: I work on a ~27,000-entry Japanese-English dictionary project (https://github.com/tkgally/je-dict-1) exclusively through Claude Code on the Web. All repo changes go through GitHub; nothing is synced to a local machine. In this setup, auto memory is effectively unusable — anything Claude writes to MEMORY.md is discarded when the sandbox is torn down, and the docs confirm memory is "machine-local… not shared across machines or cloud environments."

I've worked around it by committing all durable context to the repo (CLAUDE.md, a planning/wiki/, session logs, status files), but Claude can't write to those autonomously between sessions without a commit, which defeats the point of auto memory.

What would solve this: an account- or repo-scoped persistent memory store for the web product that survives sandbox teardown — either by exposing a configurable path that points at persistent storage (as this issue asks), or via a dedicated per-user/per-repo persistent volume.

[hilyfux]

This request makes sense to me, but I think it needs one extra boundary to avoid turning configurable paths into a subtle sync footgun.

I would split the surface into three concepts rather than a single “memory path” setting:

1. Instruction root: where the canonical CLAUDE.md / project instructions live. This can safely be a mounted Drive folder if Cowork makes the mount readiness visible before session start.
2. Memory store root: durable user/project memory, ideally inspectable and portable, but with an explicit “shared vs private” toggle because memory can contain operator-specific preferences or client details.
3. Session/cache root: transient runtime state that should stay VM-local unless the user intentionally opts into syncing it.

The important implementation detail is precedence and provenance. If Cowork loads a cloud-hosted instruction file or memory file, the UI should show exactly which path won, whether it was reachable, and when it was last read. Silent fallback to a local shim would make debugging memory drift very hard.

A pattern that has worked well for us in a separate open-source memory layer is keeping the durable memory git-native and inspectable, with append-first writes and deterministic retrieval. We built knowledge-graph around that idea for Claude Code + Codex: zero services, no opaque database requirement, and easy diff/review when memory changes. Not saying Cowork should adopt that exact implementation, but the product shape feels similar: user-visible memory, explicit source paths, and no hidden vendor silo.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.