Clerk Changelog

The Orgs tab of your Overview page now includes a report stack ranking the largest organizations in your instance by current member count.

• Top organizations at a glance: See your biggest orgs in descending order with member counts, and a link to each organization's detail page.
• Visual size comparison: Each org is rendered as a bar scaled to its member count, making it easy to see how your top orgs stack up against each other.
• Spot outliers and growth: See how usage is distributed across your tenants and catch unusual growth patterns.

Open the Clerk Dashboard⁠ and head to the Overview page to view your largest organizations.

Available now for all instances with organizations enabled.

A new elevation appearance option lets you control whether page-mounted Clerk components render inside a card (raised) or directly on the page (flush). The default is raised, preserving existing behavior.

<SignIn
  appearance={{
    options: {
      elevation: 'flush',
    },
  }}
/>

When set to flush, components drop their card background, border, and shadow, making it easier to embed sign-in, and sign-up components into your own layouts. Modals and popovers always use raised regardless of this setting.

See the appearance options documentation for more details.

Groups and custom attributes mapping are now generally available, completing the Directory Sync (SCIM) GA rollout that began with the core provisioning release. Both features are enabled for all users with no extra configuration required.

• Groups mapping assigns Clerk roles automatically based on IdP group membership. When a user is added to a group in your IdP, Clerk applies the mapped role. When they're removed, they fall back to the next mapped role. For users in multiple groups with different role mappings, a configurable precedence order controls which role wins.

• Custom attributes mapping syncs additional user data from your IdP (such as department, employee_id, or cost_center) directly into publicMetadata on the Clerk user object. Attribute definitions are configured once at the enterprise connection level and shared across both your SSO connection (SAML or OIDC) and your Directory Sync connection, so the same attributes are available regardless of how a user authenticates or is provisioned. When Directory Sync is enabled, it becomes the exclusive source for those attribute values and they're read-only in Clerk until Directory Sync is disabled.

Getting started

To enable Directory Sync, navigate to an enterprise connection in the Clerk Dashboard⁠, open the Directory Sync tab, and toggle it on. Clerk generates a SCIM base URL and bearer token to configure in your IdP.

Refer to the Directory Sync documentation for setup guides, the Role mapping documentation for groups-to-role configuration, and the Custom attribute mapping documentation for details on the shared attribute pool.

Pricing

Directory Sync, including groups and custom attributes mapping, is included with your enterprise connection at no extra charge. Refer to the pricing page for connection pricing details.

OAuth Applications now integrate with Clerk Organizations. When your instance has Organizations enabled, users going through the OAuth flow can select which organization they're acting on behalf of, and the OAuth client receives that selection as an org_id claim on the access token.

How it works

We've added a new user:org:read scope to OAuth Applications. When a client requests this scope and the user grants it, the OAuth consent screen displays an organization selector. After consent, the access token issued to the client includes an org_id claim populated with the selected organization.

If the consent screen is disabled for your OAuth Application, org_id is populated with the user's last active organization instead.

For convenience, the userinfo endpoint also returns org_name and org_slug alongside org_id, so clients can display organization context without an extra lookup.

Enabling it on an existing OAuth Application

Updating an existing OAuth Application is as simple as enabling the new user:org:read scope in its settings on the Clerk Dashboard⁠. No other changes are required — once the scope is available, clients can request it on their next authorization request.

To learn more, see our OAuth Applications documentation.

A new Logs⁠ page has been introduced into the Clerk Dashboard meant to give increased visibility into the Clerk-driven events across your applications. Application Logs track things like sign-ins, sign-ups, user updates, organization changes, billing events, and many more — enabling more detailed debugging and improved observability for your business.

Filtering and search

The logs page displays a reverse-chronological feed of events and you can narrow results using filters:

• Event type — Filter by event type (e.g., user.created, sign_in.completed). Supports trailing wildcards (e.g., sign_in.*).
• Actor — Filter by the user or API key that triggered the event.
• Subject — Filter by the resource ID being acted upon (e.g., a user ID or organization ID).
• Trace ID — Correlate events across systems using a distributed trace ID.
• Device — Filter by device ID.
• Date range — Scope results to a specific time window.

Select any log entry to view its full details, including event metadata and a JSON payload containing additional information related to the event.

Get started

Application Logs are available for all plans with varying levels of retention; see our pricing page for more details. You can access the Logs view⁠ today in the Clerk Dashboard or read the full documentation to learn more.

Going forward

App logs are just the start. We're hard at work on additional observability including Email, SMS, and Administrative logs for actions taken by your app's admins within the Clerk Dashboard and the new Clerk CLI. Stay tuned for more.

Clerk CLI is a (surprise, surprise) command-line tool for setting up and managing Clerk directly from your terminal or agentic harness. It's open source⁠ and available for you to use today.

The Clerk CLI gives both developers and agents a scriptable, terminal-based interface to Clerk so they can avoid click-ops and build faster.

Key commands

• clerk init — Detects your framework, scaffolds Clerk into your project, and gets auth ready to configure. This is the fastest way to start using Clerk in an existing or new project.

• clerk config — Manage your application's settings directly from the command line. Choose sign-in methods, configure redirects, set session policies - everything you'd normally do in the dashboard, now in code.

• clerk api — Interact with the Clerk API directly. Fetch users, organizations, sessions, and all other resources all through one command.

Try it

Use a script runner...

bunx clerk init

...or install the CLI globally and try it out today:

bun add -g clerk
clerk init

npm install -g clerk
clerk init

pnpm install -g clerk
clerk init

yarn global add clerk
clerk init

brew install clerk/stable/clerk
clerk init

curl -fsSL https://clerk.com/install | bash
clerk init

Read the full documentation or run clerk --help to see the full list of commands and options to get started.

What's next?

This is the first release of the Clerk CLI and we're working on adding more commands and features along the way to make it even more powerful.

For example, we're hard at work on clerk deploy — a single command to validate your auth setup and push it live. Deploy will handle syncing your local configuration to production, so you can go from development to launch without switching contexts.