What causes "Cannot update memories belonging to other users" in headroomlabs-ai/headroom?

Pass the memory owner's user_id (fetch the memory first to get its stored user_id) or omit user_id to skip the check

headroomlabs-ai/headroom · error · ValueError

Cannot update memories belonging to other users

Error message

Cannot update memories belonging to other users

What it means

ValueError raised by Mem0SystemAdapter.update_memory() as an ownership guard: the caller passed a user_id, the stored memory carries a non-empty user_id, and the two differ. This prevents one tenant/user from mutating another user's memories through the update path.

Source

Thrown at headroom/memory/backends/mem0_system_adapter.py:263

            ValueError: If memory not found.
        """
        # Get the existing memory using Mem0 client directly
        client = await self._backend._ensure_client()

        try:
            existing_data = await asyncio.to_thread(client.get, memory_id=memory_id)
        except Exception:
            existing_data = None

        if not existing_data:
            raise ValueError(f"Memory not found: {memory_id}")

        # Extract user_id from existing data
        existing_user_id = existing_data.get("user_id", "")

        # Validate user if provided
        if user_id and existing_user_id and existing_user_id != user_id:
            raise ValueError("Cannot update memories belonging to other users")

        # Build update metadata
        now = _utcnow()
        update_metadata: dict[str, Any] = {}
        if reason:
            update_metadata["update_reason"] = reason
            update_metadata["updated_at"] = now.isoformat()

        # Update via Mem0
        try:
            await asyncio.to_thread(
                client.update,
                memory_id=memory_id,
                data=new_content,
            )
        except Exception as e:
            raise ValueError(f"Failed to update memory: {e}") from e

View on GitHub (pinned to 322425c43b)

Solutions

Pass the memory owner's user_id (fetch the memory first to get its stored user_id) or omit user_id to skip the check
Normalize user ids at save and update time so the same string format is used everywhere
If intentional admin cross-user edits are required, call the update without the user_id argument after your own authorization check
Audit where the memory was created — it may have been saved under the wrong user_id originally

Example fix

# before
await adapter.update_memory(mem_id, 'text', user_id='alice')  # stored user_id='bob'
# ValueError: Cannot update memories belonging to other users

# after
existing = await asyncio.to_thread(client.get, memory_id=mem_id)
await adapter.update_memory(mem_id, 'text', user_id=existing['user_id'])

Defensive patterns

Strategy: validation

Validate before calling

client = await adapter._backend._ensure_client()
existing = await asyncio.to_thread(client.get, memory_id=memory_id)
if user_id and existing.get('user_id') and existing['user_id'] != user_id:
    raise PermissionError(f'{user_id} cannot edit memory owned by {existing["user_id"]}')

Try / catch

try:
    await adapter.update_memory(memory_id, new_content, user_id=requester_id)
except ValueError as e:
    if 'belonging to other users' in str(e):
        return HTTP403  # authorization failure, do not retry
    raise

Prevention

Normalize user ids (same format, case) at every save and update site
Do your own authorization before calling update; the guard is a safety net, not the policy
In tests, cover cross-user update attempts explicitly

When it happens

Trigger: update_memory(memory_id, new_content, user_id='alice') where the memory's stored user_id is 'bob' (or a differently-formatted id like 'user:alice' vs 'alice').

Common situations: Multi-tenant apps passing the requester's id instead of the memory owner's id; user id normalization mismatches (prefixed ids, case, UUID vs handle); cross-user admin tooling that legitimately needs to update others' memories.

Related errors

AI-assisted analysis of headroomlabs-ai/headroom@322425c43b (2026-08-15). Data as JSON: /api/errors/9f912fe59d789220. Report an issue: GitHub.