Skip to main content

User management

Helpers for resolving, looking up, and creating users. These live under cognee.modules.users.methods and are async, so await them.

Methods

get_default_user()

Returns the default user, creating it on first call if it does not exist yet. This is the same user Cognee resolves when you call remember(), recall(), etc. without passing user=. The default email comes from DEFAULT_USER_EMAIL (falls back to default_user@example.com); the password used at creation comes from DEFAULT_USER_PASSWORD (falls back to default_password). The auto-created default user is a superuser. See the Users concept page for the environment variables.

get_user()

Look up a user by UUID. Raises EntityNotFoundError if no user matches.

get_user_by_email()

Look up a user by email. Returns the User object, or None if no user has that email — use this for existence checks (see below).

get_user_id_by_email()

Returns just the user’s UUID for a given email, or None if no such user exists. Lighter than get_user_by_email() when you only need the id.

create_user()

Creates a new user. Raises fastapi_users.exceptions.UserAlreadyExists if a user with that email already exists.
There is no global “list all users” helper. To enumerate the users in a tenant, use get_users_in_tenant(tenant_id, user) from cognee.modules.users.tenants.methods; the requesting user must have user-management permission on that tenant. It returns a list of dicts with id, email, and roles.

Examples

get_user_by_email() (and get_user_id_by_email()) return None when no user matches, so you can check existence without a try/except:
If you prefer to attempt creation directly, catch UserAlreadyExists:
Most top-level operations resolve the default user automatically when user= is omitted, so calling get_default_user() explicitly is only needed when you want the User object itself.
Pass parent_user_id so the parent user inherits permissions on datasets the agent creates:
See Users for how parent/child permission inheritance works.