read_note and search resolve unqualified names into other accessible workspaces

[phernandez]

Summary

detect_project_from_identifier_prefix falls back to resolve_workspace_project_identifier, which searches index.entries_by_permalink across every workspace the account can access. So in a cloud/factory session an unqualified first segment can resolve to a project in a different workspace than the session's own — silently, and preferring the is_default workspace when a permalink is duplicated.

To be precise about severity: the index is scoped to workspaces the account can already access (personal plus teams), so this is not a cross-account data leak. It is a routing-correctness bug — the caller gets the wrong project, from the wrong workspace, with no indication that happened.

Reproduced form (in the POSIX resolver, before it was fixed)

Session bound to workspace beta (projects: research only); second accessible workspace acme holds notes:

resolve_project_path_route("notes/foo", project=None, project_id=None)
  -> ProjectPathRoute(project='acme/notes', path='foo', stripped=True)

Chain: the mount table declines (no mount named notes) → workspace-qualified parse declines (2 segments) → bare-prefix fallback → resolve_workspace_project_identifier("notes") matches the other workspace's project.

Status

Fixed for the POSIX tools in #1421 (b71d9d0a): that resolver now parses only fully qualified routes — workspace slug, then a project inside that workspace — and refuses an unaddressable name with UnqualifiedPathRefusedError listing the session's own mounts.

Not fixed for read_note and search, which still call detect_project_from_identifier_prefix and retain the bare-prefix fallback. They were left alone deliberately: unlike the POSIX verbs they have no mount table and no refusal rule, so simply deleting the fallback there would remove routing with nothing to replace it.

Why it is worth its own issue

The principle the POSIX surface settled on is refuse, don't default: an ambiguous or unqualified identifier should be refused with a message naming the addressable options, rather than resolved to a plausible candidate. read_note and search currently do the opposite, and they are the more heavily used tools.

Fixing them needs a decision this issue should settle: what an unqualified identifier means for a tool with no mount table. Options include restricting the fallback to the session's own workspace, adopting the same refusal with a list of candidates, or preferring the session workspace and only falling back when it has no match.

Note

detect_project_from_identifier_prefix's fallback branch is no longer exercised by the POSIX resolver, so #1421 added direct coverage in tests/mcp/test_project_context.py (hit and lookup-miss) to keep it tested while it remains in use.

[claude]

Claude finished @phernandez's task in 39s —— View job

---

Triage

Type: Bug — routing-correctness defect, not data exposure (the index is already scoped to workspaces the account can access).

Component: MCP tools — read_note and search (via detect_project_from_identifier_prefix / resolve_workspace_project_identifier in src/basic_memory/mcp/tools/read_note.py, src/basic_memory/mcp/tools/search.py, src/basic_memory/mcp/project_context.py).

Priority: Medium-High. No data leaks outside the account's own access, but resolution can silently land on the wrong project in the wrong workspace with no error — for two of the most heavily used tools. Elevated above a typical "minor bug" because it's a silent misroute, not a visible failure.

Complexity: Medium. The mechanism is understood and the precedent fix (#1421, b71d9d0a) already established "refuse, don't default" for the POSIX resolver. The remaining work is a design decision — as the issue itself flags — since read_note/search have no mount table or refusal rule to reuse as-is. Implementation is likely small once the semantics (restrict-to-session-workspace vs. refuse-with-candidates vs. session-first-then-fallback) are picked.

Duplicate check: No existing open issue duplicates this. Related history: #1421 (closed, fixed the POSIX resolver — this issue is the explicit follow-up left open by it) and #1415 (open, "Project-qualified paths: projects as mount points in the tool namespace") which is adjacent but scoped differently (mount-point design for the tool namespace generally, not this specific fallback bug). Older closed issues (#836, #834, #956, #793, #882) cover earlier rounds of workspace-qualification/routing but not this fallback path.

Note for maintainers: the issue explicitly asks for a decision on semantics before implementation — worth resolving that in a comment/discussion before someone picks this up.

[phernandez]

Related dimension: memory:// URLs also take only one segment

While closing the multi-segment project bug for the POSIX routing surface (#1421, a004ac3d), the same defect was confirmed to remain in resolve_project_and_path (the memory:// router) and in the bare-prefix fallback this issue is about.

Demonstrated by inspection:

split_project_prefix('research/2026/notes/x')  -> ('research', '2026/notes/x')     # current
split_project_permalink_prefix(...)            -> ('research/2026', 'notes/x')     # correct

So a project whose permalink contains a slash — Research/2026 — is unreachable through memory:// for the same reason it was unreachable through ls.

Why it was not fixed there

The POSIX fix works by matching a path against the known project set, which the resolver already has in hand. resolve_project_and_path and the bare-prefix fallback instead resolve a project name through the API/index, so applying the same rule means fetching a project list on every memory:// read. That is a real cost on the hottest read path, and the right trade is a deliberate decision rather than a side effect of a review fix.

Why it belongs with this issue

Both halves are the same question about the same code: what does an unqualified or multi-segment identifier mean for a consumer that has no project set in hand? Answering it once should settle:

• whether the bare-prefix fallback may resolve outside the session's workspace (the original report), and
• whether a project permalink may contain a slash on the memory:// path (this comment).

Fixing either in isolation risks a second parser that has to be taught the same lesson later — which is precisely what #1421 just removed on the POSIX side by deleting the parsers that could express the wrong shape, rather than by adding another helper.