daymug
Configure · Access & isolation

Users, SSO & sandbox.

DayMug is built to be shared. This page covers who can sign in, what they can reach, and how to keep one person's agent out of another person's files.

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 [email protected]          # prompts for a password
~/.daymug/daymug user add bob --email [email protected] --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 recipe.
  • 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, …).
  • 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.

  1. 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.
  2. 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"
  3. 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.
  4. 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.

Sandbox (bubblewrap)

On Linux, DayMug can wrap every agent run in a bubblewrap jail. A jailed agent sees its own work directory and the system files it needs to run — not other users' folders, not DayMug's database, not host secrets.

  1. Install bwrap 
    sudo apt install bubblewrap      # Debian / Ubuntu
sudo dnf install bubblewrap      # Fedora / RHEL
  2. Enable it in config.yaml and restart 
    sandbox:
  enabled: true
  type: bwrap
  network: true                     # false = agents run offline
  extra_ro_binds: [/srv/reference]   # everyone may read this
  extra_rw_binds: []                    # everyone may write this — keep it short
  3. Check the startup log. If bwrap is missing DayMug still starts — so a missing optional binary can't take you offline — but logs a line beginning with SECURITY: and runs with no isolation. 
    grep SECURITY ~/.daymug/logs/daymug.log
  4. Choose exemptions. In the Users page, each user's Sandbox is Jailed (work dir only) or Unrestricted. Admins always run unwrapped.

The same rule applies on every entry point — browser chat, the /api/v1 API and IM bots. An agent's jail follows the person who owns it.

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 a looping agent pauses instead of spending all night.