Observed in real use (2026-08-29): re-running ./cth/idp/provision.sh against a still-running CSS fails with There already is a login for this e-mail address — accounts persist in CSS's memory store across provisioning runs, and client secrets cannot be re-fetched. The temp-file guard behaved exactly as designed (users.json untouched, loud failure, run proceeded on existing credentials), so nothing broke — but true idempotence would be better for iterating. Simplest fix: a per-run random suffix in the account e-mails inside provision-css.mjs, so every provisioning run mints fresh accounts and credentials regardless of CSS state. Alternative documented in the README trap list instead: 'provision once per CSS lifetime; re-provision only after a CSS restart.'
Observed in real use (2026-08-29): re-running
./cth/idp/provision.shagainst a still-running CSS fails withThere already is a login for this e-mail address— accounts persist in CSS's memory store across provisioning runs, and client secrets cannot be re-fetched. The temp-file guard behaved exactly as designed (users.json untouched, loud failure, run proceeded on existing credentials), so nothing broke — but true idempotence would be better for iterating. Simplest fix: a per-run random suffix in the account e-mails insideprovision-css.mjs, so every provisioning run mints fresh accounts and credentials regardless of CSS state. Alternative documented in the README trap list instead: 'provision once per CSS lifetime; re-provision only after a CSS restart.'