cpatpa makes Mike log you in the moment it's installed

The installer can now hand the first administrator a working password, so there's no signup dance before anyone can get into a fresh deployment.

infrastructuresecurity

Standing up a new instance of Mike used to leave you staring at a signup form before you could do anything useful. cpatpa's fork closes that gap. During setup, whoever runs the install is asked whether to mint a password for the initial admin account. Say yes and the system generates a strong one, tucks it into the install report and a secrets file; say no and you type your own, with a minimum length enforced so nobody ships a flimsy one.

The back end then creates that admin account directly - active, fully privileged, with the password securely hashed - and records the moment in an audit log so there's a paper trail for who was created and when. A short follow-up patch cleaned up a database error in that audit step.

So what Anyone responsible for deploying or self-hosting a legal-AI tool will recognise the first-login friction this removes - and appreciate that it's logged.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

2 commits from cpatpa/PIP, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`fcc68098`	Installer + backend: seed the bootstrap admin password	Claude	2026-05-16	↗ GitHub
commit body The installer now asks during the wizard whether to auto-generate or type a password for the BOOTSTRAP_ADMIN_EMAIL account. The value is written to .env.compose as BOOTSTRAP_ADMIN_PASSWORD (and into the secrets-backup file), and surfaced in the post-install final report so the operator can sign in immediately at /login without going through the signup form first. Backend ensureBootstrapAdmin() now creates the user with the supplied password (hashed via bcrypt, cost 12) if the email doesn't yet exist. Password must be >= 12 chars or the seeding step is skipped. onboarded_at is left null so the first sign-in still goes through the onboarding wizard. The legacy "sign up via the form, get auto-promoted to admin" behaviour remains intact when BOOTSTRAP_ADMIN_PASSWORD is empty.
`35e409f6`	Fix ensureBootstrapAdmin: cast $1 to uuid and target_id to text	Claude	2026-05-16	↗ GitHub
commit body The audit_events insert in the bootstrap path was reusing $1 for both user_id (uuid) and target_id (text), which Postgres rejected with "inconsistent types deduced for parameter $1". The whole transaction rolled back, so the bootstrap user never got created on fresh installs and the operator hit "Invalid email or password" on first sign-in with no other diagnostic. Use two separate parameters with explicit casts. The metadata cast to jsonb stays.

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-370.md from inside the repo you want the changes in.

⬇ Download capture-thread-370.md