Config · Users & SSO

Users & sign-in.

DayMug works for one person or many. This page covers who can sign in, how they sign in, and how to put the server on the network safely. Keeping one person's agent out of another person's files is the sandbox's job.

Read this first

Agents run real shell commands as the user DayMug runs as. Without the bubblewrap sandbox, every agent can read and write everything that user can — including other people's work directories and DayMug's own database. Only share an unsandboxed instance with people you'd give a shell account to.

Users and admins

The first person to open an empty instance creates the first administrator. After that, admins manage everyone under Settings → Administration → Users: create users, reset passwords, set work directories, grant provider accounts and choose each user's sandbox mode — one at a time or in bulk.

From the shell, as the service user:

~/.daymug/daymug user add alice --email alice@example.com          # prompts for a password
~/.daymug/daymug user add bob --email bob@example.com --admin       # admin right away
~/.daymug/daymug user passwd alice                                  # reset a password

Work directory — each user starts in <users.default_home_root>/<username> (default ~/.daymug/users/alice). Admins can point a user elsewhere; each conversation can also pick its own folder.
Admin recovery — anyone listed in admin.bootstrap_usernames is made admin again on every start. See the field reference.
Personal environment — every user can set KEY=value lines in Settings → Advanced. They reach all of that user's agents and override the provider account's values of the same name — handy for personal tokens (GITHUB_TOKEN, …). See Environment variables.
Concurrency — users.max_concurrent (default 4) caps how many tasks one person runs at once.

Single sign-on (OIDC)

DayMug speaks standard OpenID Connect (authorization code flow with state and nonce). The examples here use Casdoor; any standards-compliant OpenID Connect provider should work the same way.

Register an application at your IdP Redirect URL: https://<your DayMug URL>/api/auth/oidc/callback. Grant types: authorization code (+ refresh token). Scopes: openid profile email. Note the client id and secret.

Add the oidc block to config.yaml

oidc:
  enabled: true
  issuer: https://sso.example.com
  client_id: "daymug"
  client_secret: "…"
  redirect_uri: https://chat.example.com/api/auth/oidc/callback
  scopes: [openid, profile, email]
  required_groups: [engineering]   # who may enter; empty = everyone at the IdP
  auto_provision: true               # create local users on first login
  button_label: "Sign in with Company SSO"

Restart and test in a private window. DayMug contacts the issuer at startup; if discovery fails the service won't start, and the log says why.
Optionally switch off passwords with auth.password_login_enabled: false — after you've confirmed an SSO admin can sign in.

Who gets in

Users are matched to local accounts by email.
required_groups, required_roles, required_permissions: a user needs at least one match in at least one non-empty list. With all three empty, anyone who can authenticate at the IdP may enter.
auto_provision: false turns SSO into a closed allow-list: an admin creates the user (with the same email) first.
Claims are read from groups / roles / permissions; rename with group_claim, role_claim, permission_claim if your IdP differs.

Casdoor tips

Token format JWT-Standard; keep the profile scope, otherwise groups, roles and permissions don't appear on userinfo. A Casdoor Permission named daymug plus required_permissions: [daymug] is a clean way to gate access.

Exposing it safely

Keep server.addr on 127.0.0.1 and put TLS in front (your own reverse proxy) — see Install → reach it.
Set server.public_url to the HTTPS address.
If your proxy doesn't forward X-Forwarded-Proto, set auth.cookie_secure: true.
Keep config.yaml private (chmod 600) when it holds an OIDC secret. Provider keys and bot tokens live in the SQLite database under ~/.daymug/data/ — protect and back up that directory accordingly.
Set guardrails so an unusually expensive task is called out before the user's next message.