`move_note` falsely reports success for unsupported cross-workspace/cross-project moves

[groksrc]

Problem

Agents (e.g. Codex) expect to move a note from one workspace/project to another. Cross-workspace and cross-project moves are not supported — but instead of failing, move_note silently performs a same-project move and reports success, which misleads the agent into thinking the note crossed the boundary.

What actually happens

1. move_note only routes project/project_id to the source project — there is no destination-project/workspace parameter anywhere in the tool, the service (entity_service.move_entity()), or the API (MoveEntityRequestV2 / PUT /v2/entities/{id}/move). The destination_path is always relative to the current project root.
2. The existing guard _detect_cross_project_move_attempt() (src/basic_memory/mcp/tools/move_note.py:17-62) only matches when a path segment equals a known project name in the same workspace. A workspace-style path (e.g. other-workspace/projects/x/file.md) sails past it.
3. The service then treats that as a relative path and moves the file to <current-project>/other-workspace/projects/x/file.md — a nested folder inside the same project.
4. The tool unconditionally reports success (move_note.py:844 "moved": True, :854 "✅ Note moved successfully"). It never compares intended destination_path against the resulting result.file_path, so a cross-boundary intent that silently degraded to a same-project move looks identical to a real success.

Suggested fix

Make the tool fail loudly instead of faking success:

• Detect cross-boundary intent and reject it with a clear error explaining cross-workspace/cross-project moves aren't supported, and the supported workaround (read_note → write_note in the target project → delete_note in the source). Broaden detection beyond same-workspace project names to workspace/project-shaped destination paths.
• Validate outcome vs. intent: if the resulting file_path doesn't match the move the agent expressed (e.g. the destination implied another project/workspace), error rather than report ✅.
• At minimum, the success message must reflect what actually happened (same project, nested folder) rather than an unqualified "moved successfully."

Notes

• Supporting real cross-workspace moves is a separate, larger feature (needs a destination-project/workspace parameter end-to-end). This issue is specifically about not reporting false success for the unsupported case.

[claude]

Claude finished @groksrc's task in 1m 58s —— View job

---

Triage Analysis

• Read issue and gather context
• Read move_note.py source to verify issue details
• Check for duplicate issues
• Classify and assign labels
• Post triage summary

---

Classification

Field	Value
Type	Bug (code defect)
Priority	Medium
Component	MCP tool (move_note)
Complexity	Medium

Labels applied: bug

---

Code Verification

The issue is confirmed by reading src/basic_memory/mcp/tools/move_note.py. Three specific gaps were found:

Gap 1 — Narrow detection (lines 41–53):
_detect_cross_project_move_attempt() only matches a path segment against known project names in the current workspace. A destination like other-workspace/projects/x/file.md has no segment that matches an existing project name, so it passes through undetected.

Gap 2 — Unconditional success (lines 843–850):

return {
    "moved": True,          # always True if no exception
    ...
    "destination": destination_path,   # agent's *intent*, not actual result
}

The resulting result.file_path is never compared against destination_path. When the silent downgrade happens, destination_path and result.file_path will differ (other-workspace/projects/x/file.md vs other-workspace/projects/x/file.md — but within the wrong project root). The agent can't tell.

Gap 3 — destination_folder bypass (lines 636 vs 704–726):
The cross-project check (line 637) runs with the raw destination_path parameter. When a caller passes destination_folder instead, destination_path is "" at that point — detection is skipped entirely. The folder is only resolved into a path at line 726.

---

Related Issue

This is an incomplete fix of closed issue #157 — [BUG] Move note to different project fails (milestone v0.14.0). That issue added _detect_cross_project_move_attempt(), but the detection only covers same-workspace project-name collisions, not arbitrary cross-workspace paths.

---

Suggested Fix Scope (medium complexity)

1. Broaden detection — after destination_path is fully resolved (i.e., after the destination_folder → destination_path expansion at line 726), re-run _detect_cross_project_move_attempt or add a secondary check for workspace-style prefixes.
2. Validate outcome vs. intent — after a successful move_entity API call, compare result.file_path against the caller's destination_path. If they don't match (or if result.file_path doesn't start with an expected project-relative prefix), return a failure with a description of what actually happened.
3. Fix destination_folder bypass — move the cross-project guard to after folder resolution (line 726+), or pass destination_target (line 505) to the check instead of bare destination_path.
4. Tests — add unit tests for workspace-style destination paths and the destination_folder bypass case.

The workaround for users until this is fixed: use read_note → write_note in the target project → delete_note in the source, as the error message already suggests.