Hay accounts
Use one Hay identity in the app and marketplace, with separate signed-in sessions.
Hay requires an account to use the desktop app. app.hay.so is the account home for both Hay and the marketplace. Your app account is shared by local workspaces on this Mac. Model-provider connections and sign-ins to other websites remain separate.
Sign in or create an account
The same email-verification flow handles both. Enter your email and verify its inbox code: an existing account signs in, or a new account is created after successful verification. Asking for a code alone does not create an account. There is no separate password signup or handle-based login.
Sign in through your browser
- On Hay’s Welcome to Hay screen, choose Continue in browser. The screen explains: Sign in or create your Hay account.
- Your default browser opens Sign in or create an account. Enter your email, then the inbox code and choose Verify and continue, if verification is needed.
- If Choose your handle appears, save your optional profile or choose Do this later. The original app sign-in request is preserved.
- Check the identity shown and explicitly choose Continue to Hay, even if the browser was already signed in.
- Choose Open Hay, allowing the browser to open the app if it asks.
The app finishes only the sign-in request it started. Merely visiting the approval page, returning to the app window or knowing the request URL does not sign it in. Requests expire after five minutes. Open browser again returns to the current request; Cancel sign-in cancels it. If it expires, start again in Hay.
Keep approval links and callback codes private. Do not forward them, paste them into chat or ask an agent to approve your account. Reloading an approved page requires another explicit Continue to Hay to create a fresh app callback.
Email-code fallback
If your browser cannot open or you prefer to finish in the app, choose Use an email code instead. Enter your email address, choose Send sign-in code, then enter the six-digit inbox value in Verification code and choose Verify and continue. No Hay password is needed.
The web sign-in page uses the same email-code service. Codes expire after five minutes, allow three wrong attempts and cannot be replayed after use. Resend is enabled after 60 seconds; server limits per address and IP still apply. Check delivery errors instead of assuming a code was sent. Enter codes directly into the trusted Hay sign-in surface, never a plugin or conversation.
Choose a public handle, or do it later
After email verification, an account without a profile is offered Choose your handle:
- Display name is the public name used for your publishing identity.
- Handle is public and prefixes published plugin IDs, such as
your-handle.little-notes. It cannot be changed yet. - Save profile saves that identity after checking the handle.
- Do this later skips setup and continues the original app request or web return page.
The whole profile step is optional. Enter both fields if you choose to save; you can use Hay without a handle and finish setup before publishing. Availability is checked while you type, but an available result does not reserve a handle. Saving is the final claim, so another person may take it first.
Handles have 3–32 lower-case letters or digits with single internal hyphens and start with a letter. Reserved and taken handles cannot be used. Display names have 1–80 characters. Review the public/permanent-handle notice before saving.
If you already have this profile, Hay reuses it. Existing signed-in sessions without a profile remain usable. Browser verification offers setup there; it does not immediately ask you to repeat it in the app. The app’s direct email-code fallback can offer setup once after a fresh sign-in.
To finish later, open Account settings / Hay account in the app. On the web account page, Finish your profile / Choose a handle opens the same setup. Share & publish also reuses this profile form. You do not need to create a second publisher identity.
Saving a profile does not publish a plugin, upload workspace records or grant capabilities. Public/private publication still requires its own code review and explicit approval.
Your account control in Hay
The small profile button in the app opens your identity and these actions:
- Account settings opens Settings / Hay account.
- Manage on web opens an account handoff in your default browser. Check the identity and choose Continue as … to open the web account page.
- Sign out of Hay signs out this Mac’s app session.
An account handoff expires after two minutes and belongs to the first browser that opens it. If that browser is signed in as someone else, the page explains the switch before you confirm it. Opening the handoff alone does not switch accounts. A used, expired or other-browser link requires a new Manage on web action in Hay.
Marketplace sign-in
The marketplace header shows Sign in or a small profile button. Its menu shows your web identity, Manage account, Open Hay and Sign out. Signing in returns you to the page you were viewing. An already signed-in browser can reuse its account identity when you explicitly approve app sign-in.
The app and browser use the same Hay identity with separate sessions. Signing in on the web does not silently sign in the app, and app sign-in does not copy a credential into browser storage. Different browsers, profiles and Hay’s built-in browser can have separate web sessions. Use Manage on web for an explicit app-to-browser handoff.
What stays local
Signing in does not upload existing plugin records, documents, conversations, source repositories or workspaces. A public or private plugin publication is a separate, reviewed code upload. A Hay account also does not automatically connect a model provider or another website.
The desktop keeps its account session encrypted outside workspace snapshots. Plugin frames and model providers do not receive it. The host sends it only to the account/API origin and its own exact personal-registry base; public and custom registries receive no account credential.
The browser session is an HTTP-only cookie on the account host. Marketplace pages receive limited profile status through a restricted account frame, not the cookie or a bearer token. No session credential is put in browser JavaScript storage or a sharing URL.
Offline work and sign-out
An already signed-in Mac can continue local work during a connection failure while its saved session remains unexpired. Online account management, publication and private-registry reads still require session validation. Expiry or server rejection returns the app to sign-in.
| Action | Session affected |
|---|---|
| Sign out of Hay in the app | This Mac’s app session, across its local workspaces. Running tools stop. |
| Sign out on the marketplace or Sign out of Hay on the web on the account page | The account session in that browser. |
These actions do not sign out every other app or browser session. Neither deletes local workspaces or published release history. App sign-out attempts server revocation and reports when it could not confirm it. An approving session must still be valid while a pending sign-in or handoff is completed.
Personal publishing
A handle chosen during optional account setup is the same personal publisher profile used for releases. If you skipped it, finish setup before your first publication. Releases use its immutable handle, such as your-handle.little-notes. Ownership belongs to the account, not a workspace name or a plugin’s author text.
Choose a public marketplace release or personal registry · Only you. Organization accounts, shared publisher roles and organization controls are not exposed yet.
Moving an existing login
The default account home and API move from the legacy accounts.hay.so host to app.hay.so. Existing valid logins are preserved; you do not need another email code just for this move.
Updated Hay recognizes an encrypted session saved for exactly https://accounts.hay.so when its configured origin is exactly https://app.hay.so. It tries the new origin first. If the new hostname temporarily fails DNS lookup, only that migrated login can retry its original trusted HTTPS account server. The app keeps the encrypted saved origin unchanged during that retry and updates it after successful validation at the new origin. Once the canonical origin responds, fallback stops. New sign-ins and custom account servers do not use this exception, and certificate or HTTP failures never trigger it. Workspace records are unchanged.
A browser’s host-only cookie cannot simply be read by another host. The legacy account site carries a valid web login through a short-lived, single-use handoff bound to the receiving browser. Check the identity and confirm Continue as … before the new host sets its own HTTP-only session cookie. A page visit alone does not approve that transfer. Pending app sign-in requests keep their original destination through the carry, so you can finish Continue to Hay afterward. The old and new host cookies refer to the same migrated web session: signing it out revokes that web session on both hosts, while an independent native session remains separate. A used or expired handoff needs a new link; normal sign-in remains available if the original session has ended.
While this narrow fallback is active, Manage on web can use a validated legacy account URL for the migrated login. It still requires explicit identity confirmation and never places a session token in the URL.
The legacy account API remains served for older clients. Bearer requests receive API responses there rather than redirects to another host. App and browser sessions keep their existing storage and sign-out boundaries.
Verification scope
Rebuilt installed Hay retained the existing signed-in account and workspace after Keychain approval. Its Manage on web used the trusted legacy handoff, verifying the scoped native DNS fallback. Chrome then carried the existing browser login to app.hay.so through explicit identity confirmation, with no new email code or sign-out.
The new origin’s HTTPS checks passed against its published address with normal TLS hostname validation. Canonical native fallback retirement is covered by regression tests but has not yet been observed live, and normal Node/macOS DNS lookup recovery remains pending. Read the operator record for those separate checks.
The clarified sign-in/create copy and optional profile offer are implemented with isolated PostgreSQL/D1 regression coverage. That coverage does not by itself verify the new onboarding UI in production.