Accounts and identities

Browser-first setup

When no Warden accounts exist, the browser opens a first-run setup screen instead of asking you to create a password hash in a shell. The first account receives the Administrator role; administrator is a role, not a permanently special account.

If an older installation still supplies WARDEN_PASSWORD_HASH, Warden requires that existing password before migrating to the first named account. Remote first-run setup also requires the one-time setup token printed by the Warden process, preventing the first Internet visitor from claiming an unconfigured instance.

Deleting a Warden account is a privileged destructive action: the acting administrator must re-enter their own Warden password. Warden also refuses to delete or demote the last enabled password-backed Administrator, preserving a local recovery path.

Account versus identity

A Warden account is the unit that owns preferences, roles, environment overrides and AI credentials and usage accounting. Login identities are attached to that account. This allows one account to have multiple usernames, email addresses or Google identities, including intentionally shared Warden accounts without forcing everyone to share one external identity.

Per-account environment

Administrators can set environment overrides on each Warden account. New terminals receive the instance-wide environment first and then that account's values, so shared defaults stay simple while individual users can override tools or paths without editing shell startup files.

Google sign-in

When an administrator enables Google authentication, a signed-in user can link a Google identity to an existing Warden account. Warden does not infer account ownership from matching email addresses and does not create accounts automatically from Google logins.

Sessions survive restarts

Authenticated sessions are persisted in the private Warden configuration directory. Restarting Warden does not automatically sign every user out; expired sessions and sessions belonging to disabled/deleted accounts are rejected.

OS authority remains separate

Warden accounts are application identities. They do not create Linux security boundaries. Every terminal and future agent task still runs with the authority of the operating-system account that launched that Warden instance. For stronger OS isolation, run separate Warden instances from separate Linux accounts.

Account lifecycle

Administrators can revoke all sessions for an account, reset individual password identities, remove login identities, and delete accounts. Password resets revoke sessions using that login identity. Warden preserves the final enabled administrator and the final login-capable identity on an account. Account deletion never deletes workspace files.

Self-service environment

Each account can manage persistent NAME=value overrides in its own Security page without needing shell access or an administrator. The values are merged over the instance-wide environment for new terminals and future agent processes.