[FEATURE] Opt-in cross-project context access for conversation search and project knowledge

Preflight Checklist

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

Problem Statement

Project scoping in Claude.ai is currently all-or-nothing, and the two halves of what makes a project useful cannot be combined with cross-context search.

Documented behavior:

• Each project has its own separate memory space and dedicated project summary, kept separate from other projects and from non-project chats. (support.claude.com)
• Anything uploaded to project knowledge is used across all chats within that project, and context is not shared across chats within a project unless it is added to the project knowledge base. (support.anthropic.com)
• Anthropic's stated rationale is containment: project boundaries keep confidential discussions separate and act as a safety guardrail. (anthropic.com/news/memory)

The result is a forced choice with no middle setting:

| | Inside a project | Outside projects |
|---|---|---|
| Pinned knowledge files | Yes | No |
| Project instructions | Yes | No |
| Search other projects' chats | No | No |
| Search non-project chats | No | Yes |

Work that legitimately spans two contexts has to be duplicated by hand or lose one half of the feature set.

Why the current design produces this

The containment rationale is sound for the case it was built for: Team and Enterprise accounts where client work must not bleed across boundaries. That is a real requirement and this proposal does not ask to weaken it.

The gap is that containment is enforced as a fixed property of the product rather than a user-controlled setting. A single account can have both requirements at once, some projects that must stay sealed and some that are just folders for organizing related work. Today both get treated as confidential silos.

Proposed Solution

Make the boundary a setting, default closed.

1. Per-project toggle: "Allow this project to search conversations outside it." Off by default. When on, conversation_search and recent_chats can reach non-project chats and chats in other projects that also have the toggle on. Requiring both sides to opt in means a sealed project cannot be read by an open one.

1. Shared knowledge references: allow a project to reference another project's knowledge base as read-only, rather than requiring the same files to be uploaded into each project separately. Duplicated files go stale independently, which is a correctness problem, not just a convenience one.

1. Explicit scope in the tool call: a search_scope parameter with values current_project and all, so scope is visible in the transcript rather than inferred. This makes the behavior auditable, which matters for the same accounts the containment rule exists to protect.

Why this is safe to add

• Default stays closed. No existing account changes behavior unless a user acts.
• Mutual opt-in means one project cannot unilaterally read another.
• Organization owners can gate the toggle, consistent with how memory itself is already gated at the org level, where owners enable it in organization settings and individual users then manage their own memory settings. (support.claude.com)
• Explicit scope in the tool call gives a clearer audit trail than the current implicit boundary.

Alternative Solutions

• Duplicate knowledge files into every project that needs them. Fragile, goes stale, and does nothing for conversation search.
• Abandon projects and work in unscoped chats. Recovers cross-chat search, loses pinned knowledge and project instructions.
• Manually paste context per chat. Error-prone at volume and defeats the purpose of stored history.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

I am a solo founder running several concurrent products, each in its own Claude project. Each project holds its own instructions, architecture notes, and working conventions as pinned knowledge, which is exactly what projects are for.

The problem is that the products are not independent. They share my stack decisions, my code standards, my brand and copy rules, and the same set of recurring engineering problems. When I solve something in one project, that solution is invisible to every other project.

I have two options, both bad. Stay inside the project and manually re-upload or re-paste the same reference material into every project that needs it, which goes stale the moment one copy changes. Or work outside projects to get cross-chat search back, and give up the pinned knowledge and instructions entirely.

For a one-person operation, this is the worst possible tradeoff. The containment guarantee is protecting me from myself. There is no confidentiality boundary between my own projects, but the product enforces one anyway, and the cost is that I re-explain the same standing context repeatedly instead of building on it.

Additional Context

Previously requested as #8648 (opened Oct 1, 2025), closed as not planned, with the autoclose label, no assignee, and no linked branches or pull requests.

Adjacent open requests in this repo cover the same shape of problem in Claude Code's memory system rather than Claude.ai projects: #36561 asks for a global memory layer persisting across projects, and #39195 asks for shared memory referenced by multiple projects rather than only global or per-project. Both note that duplicating entries across projects is fragile and leads to stale or noisy memory.