Accounts

Two places an account is edited

The desktop settings screens call the sidecar user API (/api/user/profile, /api/user/password, /api/user/git-profile, /api/user/api-keys). Studio is a separate local page. After you sign in, it writes the same SQLite tables for that user: User, a credential Account row when one exists, ApiKey, and GitProfile.

Studio does not call the sidecar and it does not run on the public site’s database. cadcam.fun serves the page; the account form works when bun run dev in packages/web has started the local Studio API against your database file.

Studio sign-in

The login form checks User.password with Bun.password (bcrypt) and stores a row in Session. The browser keeps that session in the cadcamfun-studio cookie. Sign out deletes the session row.

This is not the desktop session. The desktop uses a launch bearer token plus an optional x-session-token. A Studio cookie does not authenticate sidecar requests, and a desktop session does not sign you into Studio.

Profile

The account section edits name, title, company, location, website, bio, public profile, and show-email. Email is shown and is not changed. Name is required and must be at most 100 characters. Bio must be at most 500 characters. A website, when set, must be a URL.

The desktop profile screen sends the same fields to PUT /api/user/profile. A photo chosen in the desktop UI is stored in that browser’s local storage unless the multipart upload is actually sent; Studio does not upload a profile image.

Password

Studio checks the current password against User.password, the column its own login uses. The new password must be at least 8 characters. The new bcrypt hash is written back to User.password. If an Account row with providerId credential exists for that user, the same hash is written there too, because PUT /api/user/password on the sidecar reads that row.

There is no desktop settings control for this change-password route. Desktop sign-in, sign-up, and reset use User.password through /api/auth/*.

API keys

Creating a key inserts an ApiKey row whose keyHash is the SHA-256 hex digest of a cad_ secret. The secret is returned once. Later lists show the name and dates, not the secret. Revoking deletes that user’s row.

This is the real /api/user/api-keys store. GET /api/user/tokens and POST /api/user/tokens return a fixed demo list and do not persist anything. Studio does not offer that demo list. The desktop Account tab still reads the demo route; it is not a second key store.

Git identity

The git form reads and writes GitProfile: the name and email that sign this user’s commits. The desktop profile screen edits the same row through GET and PUT /api/user/git-profile. Saving in either place replaces the identity for that user id.

Desktop settings

Open /settings in the desktop app for the profile, account, security, notifications, AI, devices, and language tabs. Profile and git identity match the Studio fields above. The HTTP shape of every user and auth route is in Users and Authentication.

What Studio does not do

• It does not register a new user. Sign in with a user that already has a password in the selected database.
• It does not delete an account. That cascade lives on DELETE /api/user/delete-account in the sidecar.
• It does not manage passkeys. POST /api/auth/passkey-register answers 501.
• It does not edit notification preferences, AI providers, or companion devices. Those stay in the desktop.
• It does not accept the public site as a hosted account service. Without the local API, the forms stay unavailable.