Screenly 26.8.1: Pages saved with the browser extension show the signed-in view again

Wed, 12 Aug 2026 00:00:00 +0000

The browser extension is how an ordinary page behind a login gets onto a screen. You sign in as yourself, add the page with Save Authentication ticked, and the session it saves is what stands in for the person who would normally be sitting there.

Where Screenly renders that page on its own servers, the saved session was not being used the way it should. Some pages were captured logged out, showing the login form instead of what is behind it. Others worked at first and then quietly reverted to the logged-out view, once the site set a cookie of its own. And some failed on and off with nothing to explain why, which is the version that costs an afternoon.

A saved session now does what it looks like it does: the page is captured signed in, it stays signed in, and it holds up on sites that set their own cookies.

The same applies to a Cookie header you set on a web asset yourself through the API or the CLI.

Screenly 26.8.1: Signing in looks and behaves like the rest of Screenly

Wed, 12 Aug 2026 00:00:00 +0000

Signing in was the one part of Screenly that looked like it belonged to an older product. It has been rebuilt to match the dashboard: sign-in, email verification codes, two-factor, the single-sign-on flow, and creating your first workspace.

Passkey errors arrive as notifications rather than text wedged under the email field. So does a failure to send a sign-in code, which used to go unreported, leaving you waiting for an email that was never coming.

Every way of signing in works as it did, so nothing about your own credentials or your workspace’s sign-in method changes.

Screenly 26.8.1 | Screenly

Screenly 26.8.1: Pages saved with the browser extension show the signed-in view again

Screenly 26.8.1: Signing in looks and behaves like the rest of Screenly