Clerk Changelog

Clerk's MCP server gives your AI agents up-to-date Clerk SDK snippets and implementation patterns. Until now, connecting it meant editing a different config file for every client. The latest Clerk CLI release adds a clerk mcp command group that handles the whole thing:

Ten clients, one command

clerk mcp install detects the AI clients on your machine and registers the Clerk MCP server in each one you pick from an interactive list. It supports Claude Code, Cursor, GitHub Copilot (VS Code), Windsurf, Gemini CLI, Codex, opencode, OpenClaw, Warp, and Hermes Agent.

Entries are registered user-globally, so the server is available in every project. Where a client ships a usable non-interactive registration command (like claude mcp add or codex mcp add), Clerk delegates to it so the client keeps owning its config format, and writes config files directly for the rest. Re-running install always converges: whatever is already sitting under the entry name is replaced, so there's no conflict state to untangle.

clerk mcp list shows every Clerk entry the CLI has registered across your clients, and clerk mcp uninstall removes them, prompting only with the clients that actually have one.

A built-in bridge replaces npx mcp-remote

Instead of pointing each editor at a remote URL through npx mcp-remote, every client is configured to launch the same built-in bridge — clerk mcp run — expressed in that client's own config format ({ "command": "clerk", "args": ["mcp", "run"] } for most). clerk mcp run is a stdio↔Streamable-HTTP bridge built into the CLI, so there's no npx dependency, and updating the CLI updates the bridge everywhere at once with no re-install needed.

clerk doctor checks your connection

clerk doctor now probes your configured Clerk MCP server with a real initialize handshake, so you can tell the difference between "not installed", "installed but unreachable", and "working" at a glance.

Built for agents

Like every CLI command, clerk mcp respects the agent contract: non-TTY runs never prompt and emit JSON automatically, per-client failures are reported structurally in a failures array instead of aborting the run, and every registration-blocking error carries a stable code plus a docsUrl pointing at the manual setup instructions as a fallback.

Get started

Update to the latest CLI and connect your clients:

See the CLI docs for the full command reference, or the Clerk MCP server docs for manual per-client setup.

You can now configure default OAuth scopes for dynamic client registration using the OAuth applications⁠ settings in the Clerk Dashboard, or the Backend API.

This helps when OAuth clients such as ChatGPT or Claude don't include the scope parameter in their registration request⁠. A client may then request more scopes than it was dynamically registered with, resulting in an invalid_scope error. Setting default scopes helps Clerk users smooth over this commonly reported error when popular clients authenticate with their MCP servers.

Configurable default scopes give you some control over the access requested by clients that omit the parameter, which may vary per-client implementation. Clerk doesn't override a scope value that a client provides.

See the OAuth configuration guide for setup instructions.

Beginning January 18, 2027, Clerk will stop supporting CBC-mode SSL/TLS cipher suites on Clerk-managed subdomains, including clerk.example.com (Frontend API) and accounts.example.com (Account Portal). This is a breaking change for clients that can only negotiate a CBC cipher, but most applications will not be affected, since modern clients already negotiate stronger ciphers.

The change rolls out as certificates are renewed. Clerk certificates are valid for 90 days, so every affected subdomain will have moved to the new ciphers within a few months. New applications default to the new configuration starting January 18, 2027.

CBC-mode ciphers have a long history of practical attacks (POODLE⁠, BEAST⁠, and Lucky Thirteen⁠) and have been deprecated by browsers, operating systems, and the broader security community. Modern connections use AEAD⁠ cipher suites such as AES-GCM and ChaCha20-Poly1305, which avoid the entire class of padding-related attacks.

Affected cipher suites

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

After a subdomain rotates, clients that can only negotiate one of these ciphers will fail the TLS handshake with it. Any reasonably modern client (current browsers, mobile operating systems, and server runtimes) already prefers AEAD ciphers and is unaffected.

If you need continued CBC support, contact support@clerk.com.

You can now control the identifier Clerk sends to your identity provider (IdP) when a member starts a SAML sign-in. Configure the Login hint section on each SAML connection in the Clerk Dashboard⁠:

• Email address sends the member's email address. This is the default for named SAML providers.
• Custom attribute sends the value of a custom attribute that you select on the connection. Use this when your IdP identifies members with an employee ID, username, or another value instead of their email address.
• Off sends no login hint.

Custom SAML connections don't send a login hint until you select Email address or Custom attribute. Existing named SAML connections keep their email-address behavior unless you change the setting.

For setup steps and details about custom attributes, see the SAML login hint documentation.

When we released the CLI and then shipped clerk deploy, the goal was a single tool that both developers and agents could use to run Clerk end to end. CLI 2.0 pushes further into day-to-day workflows: testing webhooks and debugging as a specific user, all without leaving your terminal.

Test webhooks locally with clerk webhooks

A new command group gives you a self-contained, local webhooks toolkit — no linked project and no Platform API required:

• clerk webhooks listen: opens a relay tunnel and forwards deliveries to your local handler. Pass --token to pin a stable, shareable URL you can reuse across restarts.
• clerk webhooks verify: verifies a webhook signature offline (HMAC-SHA256), from a saved delivery or explicit header values — no network calls.
• clerk webhooks token: generates a relay token you can pipe straight into listen.

Debug as any user with clerk impersonate

clerk impersonate (alias clerk imp) creates a short-lived sign-in URL that logs you in as another user, so you can reproduce a report from their exact session. Target a user by ID or email, add --open to launch the URL straight away, and every impersonation is stamped with your account for auditing.

Run clerk imp with no arguments to pick a user interactively.

A refreshed interactive experience

Prompts, lists, and spinners have a new visual style, and interactive commands now end by clearly reflecting success, failure, or a paused cancellation — so it's always obvious how a run finished.

Built for agents

Every command in 2.0 respects the CLI's agent contract: stable error codes, stdout for data and stderr for UI, and no hidden interactive prompts in non-TTY contexts. clerk webhooks token prints a bare token to stdout so it pipes cleanly, and clerk impersonate resolves the target instance explicitly rather than silently defaulting.

Get started

Update to the latest CLI, then try any of the new commands:

See the CLI docs for the full command reference.

Just-in-time (JIT) provisioning can now be disabled per enterprise connection. By default, Clerk creates a user account the first time someone signs in through a SAML connection. With JIT provisioning disabled, sign-ins only succeed for users who already exist in your instance - anyone else is rejected instead of being auto-created. This is useful when your identity provider handles authentication but a separate system, such as Directory Sync (SCIM) or an internal admin flow, decides who gets an account.

Disable JIT provisioning

Open a SAML connection in the Clerk Dashboard⁠ and turn off Create users during sign-in in the connection's settings. The same control is available on the Backend API as a disable_jit field when updating a SAML connection or enterprise connection.

When JIT provisioning is disabled, a sign-in attempt by someone without an existing account fails with a saml_jit_provisioning_disabled error that includes the attempted email address, so blocked attempts are easy to diagnose. Existing users are unaffected and continue to sign in normally, including the first time they sign in through the SAML connection.

Compatibility

JIT provisioning remains enabled by default, so existing connections keep provisioning users exactly as before. Connections that previously had JIT provisioning disabled through the internal exception are migrated to the new setting automatically — their behavior is unchanged, it's just visible and editable in the Dashboard now.