Clerk Changelog

Five new Clerk MCP server tools let your agent inspect organizations and memberships and update existing users in your application's development or production instance.

• list_organizations: List or search organizations with filters and pagination.
• list_organization_memberships: List an organization's members with their roles and permissions.
• list_user_organization_memberships: List the organizations a user belongs to, with their role and permissions in each.
• update_user: Update a user's first or last name, username, external ID, locale, or timezone. You can also set whether they bypass Device Trust (bypass_client_trust).
• update_user_metadata: Add or change a user's public, private, or unsafe metadata.

Existing connections may not have the new organizations:read permission. Ask your agent to run whoami to check. If the permission is missing, sign out of the Clerk MCP server and connect again.

See the Clerk MCP server guide for setup instructions and the full tool list.

Agents that use a browser can now get past your app's sign-in page without asking the user for a password. By default, Clerk's Frontend API refuses sign-out, Organization switches, and profile changes from the session.

See Sign agents in to your app with a one-time link to get started.

On a paid plan, you can now set session limits per user or device, beyond your instance's custom session lifetime and native app lifetime. For example, enforce shorter sessions on a shared device, or longer ones at a user's choice. Clerk offers two ways to do this.

Revoke sessions based on age from your application

Add the session.created_at and session.expire_at shortcodes to your custom session claims to read a session's age and expiry from its token, without calling the Backend API on each request:

{
  "session_created_at": "{{session.created_at}}",
  "session_expire_at": "{{session.expire_at}}"
}

Your backend can then apply whatever rule you need, such as a different limit for business customers. When a session is past your limit, reject the request and revoke the session using the sid claim. Revoking stops the session from getting new tokens, but the token it already has stays valid until it expires, so keep rejecting requests from that session. This approach can only end sessions sooner than your instance's lifetime.

Change a single session's expiry

Use the Backend API to update a session⁠ and set a new expire_at, between 5 minutes and 10 years from now. It can be earlier or later than your instance's lifetime.

• The change applies only to that session. New sign-ins still start from your instance's lifetime.
• Expired, revoked, and other ended sessions can't be revived, and impersonation and agent sessions can't be updated.
• The session's inactivity timeout, if it has one, still applies.
• Take the session ID from the sid claim of a verified session token, or from a verified webhook such as session.created. Never take it from an unverified client request.
• Each change is recorded as a session.expiry.updated event in Admin Logs and Application Logs.

Change many sessions

Both approaches work on individual sessions. For a one-off expiry change across all active sessions, contact support.

Email events (email.*) are now part of Application Logs. You can fetch them with the GET /v1/logs endpoint of the Backend API⁠. Set type to email.* and payload_filter[recipient_email] to an address to find that recipient's emails. Call the endpoint from your own code or an AI agent to check whether a specific email was delivered to the recipient's mail server.

The Application Logs page in the Dashboard shows email events alongside every other event type, so the unfiltered feed puts a sign-up and its verification email in one timeline.

The Email Logs page still shows them, with three changes:

• Recipient, IP address, and message ID filters match exactly instead of by substring.
• Blocked sends appear as Bounced or Failed.
• Message ID shows the Clerk email ID when one is available.

Email events go back to October 5, 2026, or as far as your plan's retention period allows.

Read the list of supported events to learn more.

Application Logs⁠ in the Dashboard now group sign-in and sign-up events. Each sign-in or sign-up shows up as one row with its event count and, once it finishes, whether it completed or failed. Expand a row to see its events in order.

By default, the logs page opens on the Group view. To see one row per event, switch to List next to the refresh button. In the Group view, use the Group filter to show only sign-ins or only sign-ups, and the Status filter to show only groups that completed or failed.

Backend API

GET /v1/logs⁠ now returns grouped logs by default. If your code expects one item per event, pass view=flat.

Read the documentation to learn more.

Native sessions are sessions created by:

• iOS and Android apps, including Expo apps
• Electron apps
• Chrome extensions, on production instances only, except extensions that sync authentication with a web app

By default, native sessions follow the web browser settings, as they did before. You can set a custom maximum lifetime between 5 minutes and 10 years. Native sessions then use it instead of the web maximum lifetime and inactivity timeout. Session tokens stay short-lived, and SDKs keep refreshing them.

Changes only apply to sessions created after you save. Existing sessions keep the lifetime they were created with. To end them sooner, revoke them.

Get started

You don't need to update your SDK.

1. In the Clerk Dashboard, navigate to the Sessions⁠ page.
2. Under Native sessions, select Custom maximum lifetime and set a duration.
3. Select Save.

To make native sessions follow the web browser settings again, select Same as web, then select Save. See native session lifetime settings for details.