Administration

Users & Access

Administrators manage accounts, roles, projects, model access, plugin grants, and tool access on Users (/users). Each account also has its own permission rules for tool approvals and unattended runs.

After the first account is created, protected API routes require a bearer token. The web UI instead uses an httpOnly session cookie; browser JavaScript cannot read its token.

The public entry points include health and first-run setup checks, login routes, Microsoft SSO routes, theme and skin assets, the Web Push public key, signed avatar URLs, CLI pairing and enrollment routes, and plugin webhooks that authenticate with their own provider. Before any user exists, setup mode lets onboarding create the first administrator. Authentication is enforced after that account exists.

The very first administrator — created either by first-run setup or by the ELOWEN_BOOTSTRAP_USER/ELOWEN_BOOTSTRAP_PASS unattended path — starts with every core tool, every tool of an enabled plugin, the mcp__* family for MCP tools, every user-grantable plugin, and All models, since no other administrator exists yet to open it from Users. Every human account created after that, administrators included, receives the preset selected under Users → Options → Default settings for users → Preset for new accounts. With no preset selected it starts without model, tool or grant-gated plugin access. Preset edits also update accounts already attached to that preset.

Login tokens last 30 days by default. An administrator can change the lifetime under Settings → System. The CLI stores browser-paired credentials by origin in ~/.config/elowen/cli-instances.json; ELOWEN_TOKEN overrides the selected token. Set ELOWEN_URL to the public instance origin or its /api base, or set only ELOWEN_DAEMON_URL for direct daemon access. An older cli.json is migrated after validation; a legacy login session requires the actual direct daemon address.

elowen login
elowen chat
elowen run "Summarize the current project"

Login is limited to 10 attempts per five minutes per IP. Passwords must have at least 8 characters, and changing one requires the current password. For unattended first-boot setup, set both ELOWEN_BOOTSTRAP_USER and ELOWEN_BOOTSTRAP_PASS.

Understand administrator and member roles

Elowen has two account roles:

Administrator can manage users, host and managed projects, configuration, and account grants. A paired computer is managed only by the account that paired it. Administrators can use another account's computer only after its owner shares it with them, and cannot change its members, rename it or disconnect it.
Member can access only projects assigned to that account.

Instance-operator authority is not a third account role: every Elowen admin account has it for owner-only actions. An administrator role assigned only within a platform room does not grant that authority.

Only administrators can open Users. Members are denied access to the page and its API.

Create and manage accounts

Open Users and select New user. Enter a username and a password of at least eight characters, then choose the account's Preset and its Projects — a new personal Project or existing ones — and select Create. A human account always needs at least one Project.

Select an account to open its detail panel on the right; on a phone it fills the screen. Tabs under the name switch between its parts, and the panel opens on Permissions, which holds the project grants, voice access, spend limit, allowed models, user-grantable plugins and tool permissions. Projects assigns projects, and Account holds the display name and username, which save themselves shortly after you stop typing, and shows the account's preset, role and usage figures. Plugins that add account panels get a tab of their own. The menu next to the name changes the role, removes the account, or uses Sign in as to view the app as that account for support.

The Tools list shows each tool as enabled, disabled, or unavailable because its plugin is not granted; that last case carries a not granted badge and cannot be switched on until the plugin is granted. A tool an existing pattern already covers, such as mcp__*, carries Allowed by pattern and cannot be switched off on its own.

Reset another account's two-step verification

The Account tab shows two-step-verification status for human accounts. For another account with an enabled factor, choose Reset two-step verification only after independently verifying the person. Confirm the named target and prove your own authority: your current password, plus a new unused authenticator code if your account has the factor, or a Microsoft sign-in recorded within the last five minutes. Sign in with Microsoft again if that proof is too old. An impersonated session cannot perform the reset.

A successful reset disables the target's factor, cancels pending verification and signs out all their browser sessions. Their next password sign-in no longer asks for a code; they must enroll again under Account → Security. Their API tokens and paired computers are unchanged. A stale-state error means reload the account before retrying. An uncertain result is not a confirmed reset.

There are no recovery codes, self-reset, hidden commands or CLI recovery. A lone administrator who loses the authenticator and has neither another administrator nor usable Microsoft sign-in has no supported recovery. Arrange one of those before enabling verification.

Delete an account

Use the account's action menu to delete it. Elowen stops its running processes, removes its sessions and brain data, account settings, private memories and memory categories, push subscriptions, API tokens, project assignments, external identity links, and plugin-owned account data. Memories in a shared Project pool are not deleted; they are re-attributed. Administrators cannot be deleted; demote one first. The last administrator cannot be demoted, and the installation's last account cannot be deleted.

Chatbot accounts

A chatbot account is a non-interactive account. It has no password and no self-service sign-in, but a signed-in administrator can open it with Sign in as. It can never become an administrator, cannot be linked to an external identity, and cannot hold personal API tokens. It is bound to one Project, and that Project's instruction files are its persona (see Context Files). A chatbot account is granted the chatbot plugin when it is created.

Assign projects to a member

Project assignments control which projects a member can see:

Open Users and select the member.
In the Projects section, select Manage.
Choose the projects and save.

A member without assignments sees no project data. Administrators do not need individual assignments for host or managed Projects. A paired computer must be explicitly shared with them before it appears or can be used. The Users administration lists and counts omit computers owned by another account, even when the administrator is a member. Manage a computer's sharing from its own Project as its pairing owner. Deleting a pairing owner's account removes its computers and their Projects; deleting a shared member removes only that member's assignments. A member must keep at least one active Project: Elowen refuses a change that would leave an account without one, and demoting an account requires one.

Direct platform chats

A direct 1:1 platform chat is personal only when the sender has a verified external identity linked to an Elowen account. Groups and channels are shared conversations, even if the sender is an administrator in that platform. In a shared conversation, Elowen uses the verified sender's account-scoped state for that turn; it does not inherit the account that opened the room.

A direct chat created before its sender was linked may initially belong to the instance operator. Once the sender is verified, Elowen can adopt the chat without moving its transcript, usage, or files.

Control models, plugins, and tools

A model or tool must pass every applicable access check before it can run.

Restrict models

On the user's Allowed models control, select which configured models the account may use, or turn on All models to allow every model the installation offers, including models added later. With nothing selected and All models off, the account may use no model. A new human account starts with the selected new-account preset's grants, or no model access when no preset is selected; the first administrator starts with All models. A grant cannot add a model the installation cannot run. Personal compaction and temporary vision models use the same grant. If a chosen compaction model is later revoked, summarization uses the permitted conversation model; categorization uses that model only during the same account's active turn and otherwise skips classification.

Grant plugins

Some plugins are user-grantable and remain unavailable to every account until an administrator grants them in Granted plugins. Administrators can edit their own grants but cannot use an ungranted plugin.

A grant makes the plugin's gated tools, API routes, UI, and contributed skills eligible for that account. It does not bypass project, filesystem, or tool-permission checks. Prompt fragments, platform prompts, slash commands, and hooks are not gated by the plugin grant.

Set individual tool permissions

The user's Tools section manages a positive grant for built-in and plugin tools alike. An empty list grants no tools, including for administrators — the instance's very first administrator is the one exception, seeded with the full grant at creation as noted above, and a new human account gets its preset's tool grants. Patterns such as mcp__* can cover matching tools. A tool unavailable because its plugin is not granted must be enabled through the plugin grant first.

A saved tool grant may remain while a plugin is disabled or a personal MCP server is offline; it matches no tool until that tool becomes available again. Unknown tool names have no effect.

A terminal grant does not automatically provide unrestricted host access. By default, commands from non-operators are confined to their available projects and the account's home directory; an administrator turns that off with Confine non-operator commands in the Environments plugin settings. File tools keep their own path boundaries, and commands in a managed project run inside that project's environment.

Set permission rules

Open Account → Models → Command permissions to choose what happens when an available tool is called. Changes save immediately.

Each rule has one action:

allow runs without approval.
ask requests approval when a human approval surface is available.
deny refuses the call.

The tools pattern matches a tool name, such as Write. The bash pattern matches the shell command string, so git * and rm * can have different decisions even though both use the Bash tool.

Rules run in order and the last matching rule wins. User rules follow built-in defaults, so a user rule can override a default. If no rule matches a tool call, the result is ask.

A shell line with multiple simple commands, such as cd app && rm -rf build, is split at ;, newlines, &&, ||, |, and &, and into the inner command of every substitution such as $(…) or backticks. Each command is checked separately. The most restrictive result applies: any deny blocks the whole line, otherwise any ask asks.

Use YOLO mode

YOLO mode in Account → Models changes ask decisions to allow without prompting. It does not override an explicit deny or make an unavailable tool available. It is off by default; the toggle sets the default for new sessions, and /yolo in elowen chat changes the current session only.

Choose unattended ask behavior

Scheduled runs, delegated sub-agents, and chat platforms have no person waiting to approve a tool call. Account → Models → Unattended runs controls how ask rules behave there:

Allow is the default and treats ask as allowed.
Block refuses ask calls in unattended turns.

This setting is independent of YOLO; YOLO does not override unattended denial. Read-only delegated sub-agents always refuse ask calls, whatever this setting says.

Set defaults for users

Open Users, choose Options, then Default settings for users. Set the models, memory, automatic skill learning, style and instructions, language, tool rules and YOLO that human accounts should use while they have no value of their own. The conversation model uses the installation's existing default. The Plugins section edits personal plugin defaults; secret credentials remain personal.

Each setting shows how many accounts have their own value. Apply to everyone asks you to confirm clearing those overrides, after which the accounts follow the default. Changing a default alone preserves every account's own choice. Chatbot accounts keep their own settings.

Preset for new accounts selects a named account preset or None, including for Microsoft SSO. The creation dialog starts with that selection and lets you choose another preset or none. The first administrator keeps full access; chatbot accounts cannot use presets.

Use account presets

Open Users → Options → Account presets and choose New preset. Give it a name such as Operator or Sales, then configure its Permissions, Behavior and Projects. Assign it with Preset in an account's detail or when creating a human account. Each account can have one preset; the account list and detail show its name beside the account role.

Changing a preset updates every attached account immediately. Grants include models, tools, plugins, voice, Project permissions and monthly spend. Behavior fields are optional: an account uses its own choice first, then the preset, then the installation's defaults. Overwrite everyone in this preset clears personal choices for the selected field only among attached accounts. Personal changes made from Account keep the preset attached. The conversation-model default and personal plugin settings remain outside presets.

Before you change an attached account's permission manually, Elowen asks you to confirm detachment. The manual change stays and future preset edits no longer affect that account. Selecting no preset also detaches it while preserving grants and Project memberships.

Projects in a preset are minimum memberships. Extra memberships remain, and removing a preset Project removes that membership unless it would leave a member without an active Project. In that case the account keeps the Project and the response lists it.

Deleting a preset asks you to confirm the number of attached accounts. Those accounts retain grants, personal settings and Project memberships; behavior without a personal choice follows the instance defaults again. On upgrade, existing new-account model, plugin and tool grants become the preset Nový účet, selected for new accounts.

Upgrade from Microsoft SSO defaults. The Microsoft SSO provisioning settings for default models, default plugins, allowed tools, the preferred model and YOLO move to the instance defaults on upgrade. Each value fills only an empty slot, so a value you already configured stays. If Microsoft Teams previously had ssoDefaultYolo enabled and no shared permissions default is stored, YOLO becomes the default for every human account without its own rules, including existing accounts and accounts created outside Microsoft SSO. Accounts with their own permissions settings keep them. Review the legacy setting before upgrading and the shared Rules and YOLO section under Users → Options → Default settings for users afterwards.

Read the Activity feed

The Activity feed is an operational overview, not a complete audit log. It records turn activity, SSO events, and plugin events that explicitly publish them. Activity is grouped into short time windows and kept for the configured retention period, 30 days by default.

The team feed shows limited actor, surface, count, and tool-summary information, not message text, commands, paths, or every request. Some older, unattributed, failed, or otherwise unrecorded work may be missing. Account memory changes have a separate user-scoped audit trail.

Delegated sub-agents

A delegated sub-agent receives an access scope from its parent, including administrator status, project access, tool policy, permissions, and read-only state. Delegation can narrow access but cannot grant broader access than the caller has.

Read-only mode removes write tools and restricts shell commands, but is not a filesystem sandbox: shell redirection can still write wherever the surrounding path permissions allow. Continuing a child is refused if its stored scope exceeds the caller's current authority. A read-only child can be given write access only by the principal who requested it, and only when the caller's current access permits it.

Administer users through the API

The web UI is the recommended administration surface. Administrators can also use the authenticated CLI:

elowen api GET /users
elowen api GET /users/12/projects
elowen api POST /users/12/projects '{"projectId":3}'

Administrator routes include GET /users, POST /users, PATCH /users/:id, DELETE /users/:id, project assignment routes, and user tool and stats routes. The API uses the same bearer token as the CLI.

Link external identities and configure SSO

An external identity is uniquely bound by provider, tenant, and subject. An identity can belong to only one Elowen account, and an account cannot hold two subjects for the same provider and tenant. Email is only a controlled linking aid; the external subject identifies the account.

Microsoft SSO works only when the Microsoft plugin is enabled and its SSO switch is on. It is limited to its configured tenant. Matching a unique email can link an account by default, but ambiguous matches are refused and an existing subject binding takes precedence. Automatic account creation is off unless ssoProvision is explicitly set to tenant. Provisioned accounts start as passwordless non-admins, created the same way an account created in Users is: their Project comes from the plugin's ssoNewPersonalProject and ssoDefaultProjects settings, and their grants and preset Project memberships come from Preset for new accounts under Users → Options → Default settings for users. With no preset selected their grants start closed. Behavior is inherited from the preset and instance defaults rather than copied into personal settings.

Provisioning also requires Microsoft Graph to confirm an enabled member account. Guests, disabled or non-member accounts, and unavailable directory checks are refused. SSO cannot create the installation's first administrator; create that account through first-run setup.

Next: Troubleshooting