Versions
v2.6.172026-10-10patch release

Password reset emails work again

Asking for a new password from the login page had two separate problems. The first one you could see: sometimes the request failed with a technical error saying a domain was not allowlisted. That happens when the address you opened Portail from is not on our sign-in provider's list of approved sites, so it refused to build a reset link that points back to it. Now, when that happens, we still send you the reset email, just without the Continue button that takes you back to Portail at the end, and you no longer see a raw error with the word Firebase in it. The second problem was quieter. Even when the email did go out, the link in it brought you back to the login page without ever letting you pick a new password, because we had told the provider that Portail would finish the reset itself and no page on our side was doing that. Now the link opens a simple page where you type your new password, and once it is saved a Continue button brings you back to Portail so you can log in with it. Nothing changes about your account, your saved chats or your plan, and passwords you already use keep working. If you requested a reset recently and the link did not help, request a fresh one and it will take you to the new page. Links from older emails may already have expired, which is normal for reset links.

621 words

Reset links now open a page where you actually set your new password, then bring you back to Portail.

The "Domain not allowlisted" error no longer stops the reset email from being sent.

Nothing about your account, chats or plan changes.

Portail v2.6.17 shipped on 2026-10-10 as a patch release focused on password reset emails work again. Asking for a new password from the login page had two separate problems. The first one you could see: sometimes the request failed with a technical error saying a domain was not allowlisted. That happens when the address you opened Portail from is not on our sign-in provider's list of approved sites, so it refused to build a reset link that points back to it. Now, when that happens, we still send you the reset email, just without the Continue button that takes you back to Portail at the end, and you no longer see a raw error with the word Firebase in it. The second problem was quieter. Even when the email did go out, the link in it brought you back to the login page without ever letting you pick a new password, because we had told the provider that Portail would finish the reset itself and no page on our side was doing that. Now the link opens a simple page where you type your new password, and once it is saved a Continue button brings you back to Portail so you can log in with it. Nothing changes about your account, your saved chats or your plan, and passwords you already use keep working. If you requested a reset recently and the link did not help, request a fresh one and it will take you to the new page. Links from older emails may already have expired, which is normal for reset links. The work is recorded here because small releases are still product history. They change how people sign in, read responses, pay for access, share conversations, open files, or trust the system when something goes wrong.

The main changes were direct: reset links now open a page where you actually set your new password, then bring you back to portail, the "domain not allowlisted" error no longer stops the reset email from being sent, and nothing about your account, chats or plan changes. That list is intentionally plain. It names what changed without turning the release into theatre. When a release fixes a build, a redirect, a storage path, or a UI edge case, the value is often that users stop noticing the problem. The archive keeps that invisible work visible enough for future debugging and for anyone checking whether Portail has cared about the details over time.

This version also fits into the wider Portail contract. One account, one chat history, and one model picker only work if the smaller pieces keep their promises. Authentication has to fail clearly. Billing has to count honestly. Uploads have to arrive in a form models can read. Admin tools have to show the operator what happened instead of hiding it behind a blank screen. v2.6.17 moved that contract forward in its own narrow lane.

The screenshots attached to this entry show the public release record as it now appears on portail.cc. For older releases, this archive was rebuilt from the git history, package version changes, release modal text, and commit subjects. That means the page is honest about its source: it documents the shipped change and preserves the record going forward, even when the exact old production screen cannot be recreated from a single saved image.

The practical result is simple. Someone landing on this page can see the version number, date, release tier, headline, highlights, and a real rendered screenshot of the archive page. Search engines can index the post through the canonical URL, sitemap entry, and structured data. Future releases now have a standard to meet before deploy, so the history should get cleaner from here instead of fuzzier.