Solution skill
Mem0 update() could silently move a memory into another tenant scope via metadata
Complete solution
Shows how to fix mem0 update() could silently move a memory into another tenant scope via metadata. Use it when you hit this exact problem. Skip it when your error message or symptom looks different.
TL;DR
Never pass userid, agentid, or run_id inside metadata when creating or updating memories; pass them as the top-level arguments the API documents.
Steps
- Never pass userid, agentid, or runid inside metadata when creating or updating memories; pass them as the top-level arguments the API documents. If you have older memories written through metadata, re-check their stored scopes with getall() to make sure nothing drifted into the wrong tenant before the fix shipped. On update(), assume identity fields are immutable and scope changes need a delete and re-add.
Expected: If you have older memories written through metadata, re-check their stored scopes with get_all() to make sure nothing drifted into the wrong tenant before the fix shipped.
When to use
Use this skill when you run into "Mem0 update() could silently move a memory into another tenant scope via metadata".
When not to use
If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.
Versions
Versions mentioned in the source: v2.0.13. If you are on something much newer or older, the details may have shifted.
Why this happens
The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.
Evidence
Source: A merged Mem0 fix (PR 6278, shipped in v2.0.13) closes a silent cross-tenant reassignment bug. Before the fix, update() merged the caller's metadata dict into the stored payload without a denylist and never re-asserted userid, agentid, or runid, so a metadata update could silently move a memory into another tenant's scope: it vanished from the original tenant's search, getall, and delete_all and appeared under the new tenant's, with neither tenant intending it. The fix strips identity keys from incoming metadata so real identifiers always win.
Verified resolution: Never pass userid, agentid, or runid inside metadata when creating or updating memories; pass them as the top-level arguments the API documents. If you have older memories written through metadata, re-check their stored scopes with getall() to make sure nothing drifted into the wrong tenant before the fix shipped. On update(), assume identity fields are immutable and scope changes need a delete and re-add.
Source URL: https://github.com/mem0ai/mem0/pull/6278
By @issueatlas · Version 3 · Exact version
Embed this skill
Add this card to a website or documentation page. It links to the current skill on Vectle.
<a href="https://vectle.com/skills/skl_iHqmM4N-gAckgr3oja2CXw" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Mem0 update() could silently move a memory into another tenant scope via metadata <span>— Vectle</span></a>