[ttypic]

The 2.0.0 release gets the CLI ready for MAU-based pricing, where Ably bills each distinct client ID that connects from a device. Until now every CLI command connected as a new random client ID, so a single terminal session could look like dozens of users. The CLI now connects as a server, which is not counted as MAU, and acts as one stable client ID that you can see in the "Using:" banner and choose yourself.

This release also changes what ably apps rules create matches, to work the same way as the rules the dashboard creates.

Breaking changes

• ably apps rules create "chat" used to create a rule for chat and every channel beneath it, such as chat:room1. It now creates a rule for the channel chat alone. To cover the channels beneath it, use ably apps rules create "chat:*". Existing rules are unaffected and keep matching as before.
• Long-running commands, such as subscribe and enter, now exit with a non-zero code when their connection fails, or when it drops five times in a row without staying connected for 10 seconds. Previously they logged a warning and exited with 0, so a script could not tell that it had stopped receiving messages.
• When a long-running command reaches --duration, its --json output ends with the standard {"type":"status","status":"completed"} line, the same as every other command, instead of a separate complete line.
• An empty client ID is rejected instead of silently falling back to a random one, and * is rejected as the CLI's own client ID. --client-id none still works but is deprecated and prints a warning.

One client ID per install

• The CLI acts as one client ID for every command, every command in ably interactive, and every token it issues. It is chosen from the first of --client-id, ABLY_CLIENT_ID, client.id in ~/.ably/config, or a default generated once per install and saved in the config.
• The "Using:" banner shows the client ID the command acts as.
• To act as another user, for example to demo two users chatting, pass --client-id in each terminal.
• Under token auth, the client ID comes from the token and is never overridden. A JWT without an x-ably-clientId claim is rejected before connecting, with an explanation.
• ably bench gives each process its own client ID, so many concurrent bench processes do not hit the per-client-ID connection limit.

Server connections

• The CLI is built on @ably/pubsub-server 3.0.0 instead of ably 2.x, with @ably/chat 2.0.0 and @ably/spaces 0.6.0 on the same core. Every Pub/Sub, Chat and Spaces connection the CLI makes is a server connection.

Tokens

• ably auth issue-ably-token and issue-jwt-token always show who the token is for: Client ID: anonymous in human output and clientId: null in JSON, rather than leaving the field out.
• ably auth issue-jwt-token --client-type server issues a JWT whose holder connects as a server.
• --client-id "*" still issues wildcard tokens.
• ably auth revoke-token uses the endpoint you are configured for, instead of always calling rest.ably.io, and reports a failure for each target separately.

Channel rules

• ably apps rules create creates rules whose ID is a match expression, with the same syntax as a capability resource: chat:*, *:presence or foo:*:baz.
• ably apps rules create, update and list show each rule's mode, matcher or namespace, since the same ID matches different channels in each. update keeps the mode a rule was created with.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
cli-web-cli	Ready	Preview	Nov 2, 2026 1:23pm UTC

[claude-code-ably-assistant]

Walkthrough

This is the v2.0.0 release PR for the Ably CLI, bumping the package version from 1.3.0 to 2.0.0 and adding the corresponding CHANGELOG entry. The release itself was delivered via the integration branch merged in #467 — this PR contains only the release bookkeeping (version bump + changelog). The v2.0.0 milestone gets the CLI ready for MAU-based pricing by switching to server connections and introducing a stable, per-install client ID.

Changes

Area	Files	Summary
Config	package.json	Version bumped from 1.3.0 → 2.0.0
Docs	CHANGELOG.md	Full [2.0.0] entry added: breaking changes, client-ID behavior, server connections, token changes, and channel rules changes

Review Notes

• Breaking changes documented in this PR (implemented in Integration: MAU-based account support and SDK dependency upgrades for next release #467, captured here in the changelog):
  • ably apps rules create "chat" now matches only the literal channel chat, not chat:* descendants — callers must update invocations.
  • Long-running commands (subscribe, enter, etc.) now exit non-zero on connection failure or five consecutive drops — scripts relying on exit code 0 will need updating.
  • --json duration-exit output changes from a custom complete line to the standard {"type":"status","status":"completed"} envelope — any tooling parsing that line must be updated.
  • Empty client IDs and * as --client-id are now rejected rather than silently falling back.
• No code changes in this PR — the diff is two files (version + changelog). Behavioral risk lives entirely in Integration: MAU-based account support and SDK dependency upgrades for next release #467.
• Dependency changes (reflected in changelog, pinned in Integration: MAU-based account support and SDK dependency upgrades for next release #467): @ably/pubsub-server 3.0.0, @ably/chat 2.0.0, @ably/spaces 0.6.0 — these replace the ably 2.x package and carry their own semver guarantees.
• npm publish: once merged, this tag should trigger the release pipeline — confirm the publish workflow is wired to this branch/tag.

[claude-code-ably-assistant]

Review: Release v2.0.0

This PR is a release-only change: the 2.0.0 changelog entry and the package.json version bump. No source code changed, so the command/test/output checklist doesn't apply.

Changelog

• Content matches the PR description exactly — good consistency.
• Date (2026-11-02) is correct.
• Breaking changes section is clear and actionable, with concrete migration steps for users (e.g. "chat" → "chat:*").
• The version jump from 1.3.0 → 2.0.0 is appropriate given the breaking changes documented (exit code behavior, client ID rejection, JSON output contract change for --duration).

One minor note worth verifying before merge: The PR description mentions @ably/pubsub-server 3.0.0, @ably/chat 2.0.0, and @ably/spaces 0.6.0. It's worth a quick sanity check that package.json dependencies reflect those exact versions — the diff doesn't show the dependency lines, only the version field, so this can't be confirmed from the diff alone.

No issues blocking merge.