Cloud/Web sessions need a personal memory layer bound to the user, not the execution location or repository

Preflight

I searched existing requests. This overlaps with, but is distinct from, the issues listed under "Related work" below. The distinctive ask here is a user-owned, external-storage-backed personal memory layer that reaches ephemeral cloud/web containers, auto-loaded at session start.

Background / Problem

Local Claude Code lets a user accumulate their own context and working preferences in ~/.claude and CLAUDE.md, so the assistant can be "grown" across sessions. Cloud/Web sessions, however, clone the repository fresh on every startup by design (ephemeral containers), so nothing that isn't committed to git carries over.

This leaves only two options, both bad:

1. Re-explain the same context every session — cross-cutting rules evaporate.
2. Force personal/common rules into git — things that should be managed in one place get duplicated and demoted into per-project rules, with inconsistent granularity across projects, breaking any unified management.

This is not a "local vs. cloud" location problem. The real gap is that memory is bound to the execution location and to the repository, but not to the user. It is the same problem as a single user with multiple machines being unable to keep one unified md — that same fragmentation now happens between local and cloud.

Concrete example (happened to me this week). I had a local Claude Code session with a maintained personal memory layer (MEMORY.md + a memory/ directory of user/project facts). A separate cloud session then continued the same piece of work on the same repository — and it started with none of that context, because none of it lives in git. Same user, same task, same repo; the two sessions had completely different levels of understanding of who I am and how I work. The split is not hypothetical.

Related work (and how this differs)

• #14228 — "Claude Code should access user's claude.ai memory": shares the goal ("one Claude that knows me across interfaces"), but proposes syncing with claude.ai's memory / a shared internal API. It does not address the cloud ephemeral-container mechanism, nor a user-owned external-storage home for the memory. This request is complementary: it names the storage/ownership model and the cloud gap explicitly.
• #70494 — "Automatic memory recall at session start": overlaps with the make-or-break requirement below (auto load at start), but is about the local memory system not reliably activating; not about cloud sessions or external storage.
• #67383 — "Request early access to Session Memory" (and the tengu_session_memory / autoMemoryEnabled / autoDreamEnabled mechanisms it references): indicates account/session memory is already in staged rollout. The open questions this request raises: is Session Memory execution-location-independent — does it reach ephemeral cloud/web containers? — and does it allow user-owned storage, or is the data held by Anthropic? If Session Memory already covers cloud + user ownership, this can fold into it; if not, that is exactly the gap.

Proposal

Let users store a personal memory file in CLAUDE.md format in storage they own (e.g. Google Drive / Notion via the existing connectors), and automatically load it into context at session start.

• The memory is owned by the user → privacy stays with the owner (Anthropic does not have to hold personal data).
• Independent of execution location and repository → the same context follows the user across devices and cloud.
• git holds "project-specific" rules; external storage holds "personal/cross-cutting" rules — the layers separate naturally.

The make-or-break requirement

It must be an automatic bootstrap load at session start. If it stays a "fetch-on-demand tool," it degrades into "please read my md again every time" and solves nothing. (See #70494 for how the local system already suffers from exactly this when auto-load is unreliable.)

Why user-owned external storage (rather than Anthropic-hosted account memory)

An Anthropic-hosted, account-scoped memory would also achieve location independence, and may be the simpler path. This request argues for at least supporting user-owned storage because:

• Data sovereignty — personal context stays in storage the user controls; Anthropic doesn't have to hold it.
• Portability / export — the user can read, diff, back up, and move the file themselves; it isn't locked inside a product.
• Implementation leverage — the connector plumbing (Drive/Notion) already exists.

Also worth considering

• A precedence rule for when the external-storage md and the repository CLAUDE.md conflict.
• Size / token budget: auto-loading a large personal md into every session has a cost. An index-first approach (load a short index, lazy-load the bodies it points to) keeps this bounded — the local MEMORY.md + memory/ split already works this way and is a good model.
• Authorization / data-exposure when an ephemeral container connects to personal storage (a fresh access path is opened every session). A pre-issued read-only token held in config, rather than an interactive auth flow at every startup, avoids opening that path repeatedly and keeps headless runs working.
• Graceful handling for headless / scheduled runs where connectors may be unavailable.

<details>
<summary>日本語（参考）</summary>

ローカル版は ~/.claude / CLAUDE.md に利用者ごとの前提を蓄積して「育てる」ことができるが、クラウド/Web版は起動のたびにリポジトリをまっさらにクローンする ephemeral 設計のため、git に入っていない情報は引き継がれない。これは「ローカルかクラウドか」ではなく、記憶が実行場所・リポジトリに紐づき、利用者本人に紐づいていないという構造欠落。

実例：今週、個人記憶レイヤー（MEMORY.md＋memoryディレクトリ）を持つローカルセッションと、同じ作業を続けたクラウドセッションがあったが、後者はその文脈をまったく持たずに始まった（git に無いため）。同一ユーザー・同一リポジトリなのに理解度が別物。

提案：利用者所有の外部ストレージ（Drive/Notion 等の既存コネクタ）に CLAUDE.md 形式の個人記憶を置き、セッション開始時に自動ロードする。git＝プロジェクト固有、外部ストレージ＝個人・横断、とレイヤーが自然に分離する。要件は「起動時の自動ブートストラップ読み込み」であること（fetch-on-demand では意味がない）。Anthropic ホストのアカウント記憶でも location 非依存は達成できるが、データ主権・可搬性・既存コネクタ流用の観点から、少なくとも BYO ストレージの対応を求める。既存の #14228 / #70494 / #67383（Session Memory）との差分は「クラウド ephemeral への到達」と「利用者所有ストレージ」。

</details>