Vercel comments CLI, 20 August 2026: a 2018 doc stamp and an empty permissions block

Summary. Vercel shipped vercel comments on 20 August 2026, a command that lists, replies to, resolves, edits and permanently deletes Vercel Toolbar comment threads from a terminal. The reference page for that command, vercel.com/docs/cli/comments, carries the frontmatter field last_updated: 2018-10-20 — a stamp eight years older than the feature it documents, and the oldest of the seven Vercel comment and CLI pages we pulled. The same page opens with a "Permissions Required" block that names no role, no plan and no scope, on a command whose own text says "Deletion cannot be undone." It also never states a minimum CLI version, while the npm canary dist-tag for the vercel package currently points at 51.7.0, eight major versions behind latest at 59.5.0 (published 22 August 2026). Comments are on by default for every preview deployment on every plan, free of charge, so the blast radius is every Vercel team, not a paid subset.

What actually shipped

The changelog entry, published 20 August 2026 under the bylines of Julian Benegas, Vishal Yathish and George Karagkiaouris, describes vercel comments as covering "the full triage loop": list and filter unresolved comments for the linked project scoped to the current Git branch, inspect a thread with every message and its IDs, and reply, resolve, reopen, edit or delete from the terminal, with --format json output for scripts and agents.

The reference doc fills in the parts the changelog left out. list is the default subcommand and returns unresolved threads only; --status accepts unresolved, resolved or all. --limit takes 1 to 100 and defaults to 20, with the next page reached through -N, --next and a cursor that JSON output returns as pagination.nextCursor. Replies accept Markdown from --message, --file or standard input, and --attach takes up to 10 HTTPS URLs — local file uploads are not supported. --author accepts a user ID or the literal me, and the doc notes that me "requires user authentication, and usernames are not supported", which rules it out of any pipeline running on a team token.

None of that is the problem. The problem is what the surrounding documentation does not say.

The reference page predates the feature by eight years

Vercel docs expose a last_updated field in the frontmatter of every .md version of a page. Pulled on 24 August 2026, the comment-related set reads like this.

A stale timestamp on a brand-new page is not cosmetic. Retrieval systems, internal doc mirrors and coding agents routinely sort or filter on that field, and several teams gate "is this doc current?" checks on it. A page dated 2018-10-20 will be treated as the least trustworthy document in the set by any tool that reads the stamp, when it is in fact the only one describing a four-day-old command. We have seen the reverse pattern before, where a vendor's reference page quietly lagged the changelog by months; here the metadata is wrong in a way that is trivially checkable and still wrong.

A permissions block with no permissions in it

Both /docs/cli/comments and /docs/comments open with the same construction: a lock glyph, the words "Permissions Required", and then the name of the thing. On the CLI page it reads "Permissions Required: The vercel comments command". That is the entire block. No role list, no plan gate, no token scope, no statement of whether a Member can delete a message written by an Owner or by an external collaborator.

That matters more here than on a read-only page, because delete is destructive and the doc is explicit that "Deletion cannot be undone." Comments are, per the overview page, "enabled by default on all preview deployments, for all account plans, free of charge", with external collaborators invitable on Pro and Enterprise. So the population that can hold a comment thread is broad, and the population that can destroy a message in one is undocumented.

The practical read: until Vercel fills that block in, treat vercel comments delete as an unbounded action and keep it out of any non-interactive automation. The same caution applied to token scoping in our note on Vercel Connect connector revocation and billing gaps.

Two confirmation conventions inside one command

The command ships two opposite safety defaults, four paragraphs apart in the same page.

So vercel comments delete <thread> <message-id> prompts, and vercel comments resolve <thread> does not. A reviewer who resolves the wrong thread ID gets no second chance at the prompt; a reviewer who deletes gets one. This is the second time in a fortnight that a Vercel CLI surface has carried inconsistent confirmation behaviour, after the JSON-mode prompt problem we covered in Vercel CLI project and domain commands blocking CI on confirmation.

There is a second, sharper contradiction in the JSON section. The page states that "JSON output does not prompt for missing input or confirmation", and separately that for delete you should "Pass --yes in non-interactive or JSON mode." Both cannot be operationally true in the way a script author would read them. If JSON mode never prompts, --yes is redundant; if --yes is required, JSON mode is refusing the operation rather than silently proceeding. The doc does not say which, and the difference is the difference between a pipeline that deletes and a pipeline that exits non-zero. Bulk operations, the page adds, "continue after an individual thread fails and exit with a nonzero status if any operation fails", so a partial delete is a documented outcome.

The version gap nobody wrote down

The reference page contains the string "version" zero times. It never names the CLI release that introduced vercel comments, and there is no "available since" line.

Meanwhile the npm registry shows vercel at latest 59.5.0, published 22 August 2026, with 59.3.0 published 20 August 2026 at 17:43 UTC — the same day as the changelog post. The canary dist-tag points at 51.7.0. Anyone who follows the widespread habit of installing vercel@canary to get "the newest build" lands eight major versions behind latest, on a release that predates the command entirely. The package declares engines.node >= 18.

The changelog's own agent prompt says "Ensure the vercel CLI is up-to-date." An agent handed that instruction has no documented version number to check against, and the obvious @canary shortcut moves it backwards. Pin the exact version instead:

npm i -g vercel@59.5.0
vercel comments --help

The CLI docs also note that native CLI binaries are "available as an experimental opt-in install" for containers, CI jobs and managed developer workspaces. Experimental binaries plus an undocumented minimum version is a combination worth avoiding in CI this month.

What to do this week

Check your own exposure in the order a build engineer would. First, run vercel comments --help on a pinned 59.5.0 and confirm the subcommand list matches the doc, because the doc's stamp gives you no assurance either way. Second, audit any automation that shells out to vercel comments: add --yes explicitly where you intend a destructive action to proceed, and add an explicit exit-code check, since bulk operations exit non-zero on partial failure. Third, keep delete out of agent-driven loops until the permissions block names roles. Fourth, remember that --page filters on the recorded path, and the doc warns that "Rewrites can cause the recorded path to differ from the browser URL", so a filter built from your public routes may silently match nothing.

For teams that run preview review at scale, the durable fix is the same one that applies to every CLI-driven review loop: treat the terminal path as a second interface to the same data, and give it the same access model you gave the browser. That work sits inside the wider web platform and interoperability practice, alongside the observability and cost questions we raised in Vercel always-on tracing span pricing.

India-specific considerations

Indian product teams working with US or EU clients typically hold Member-level access on the client's Vercel team rather than Owner. Because the permissions block is empty, an offshore reviewer cannot tell from the docs whether vercel comments delete will succeed against a client-authored message or fail with a permissions error, and finding out by running it against production feedback is not an acceptable test. Under the Digital Personal Data Protection Act 2023, comment threads that quote customer names, order IDs or support text are personal data in your processing chain, and an undocumented, irreversible delete path is a poor fit for a retention policy you have to be able to describe. Until Vercel documents roles, keep deletion in the browser where the actor is visible in the thread.

What is still unknown

Vercel has not stated which release added the command, which roles may delete, whether --yes is required or merely permitted in JSON mode, or whether the 2018-10-20 stamp is a template default or a broken build step. The .md frontmatter is machine-readable and public, so the stamp is easy to fix; the permissions block is the one that needs an actual policy decision written down.

FAQ

When did Vercel release the comments CLI?

Vercel published the changelog entry titled "Manage Vercel Toolbar comments from the CLI" on 20 August 2026. On the same day the npm registry recorded vercel 59.3.0 at 17:43 UTC. The current latest release is 59.5.0, published on 22 August 2026, which is the version to pin.

Why does the reference page say last_updated 2018-10-20?

Vercel has not explained it. The field appears in the frontmatter of the Markdown version of vercel.com/docs/cli/comments, and it is the oldest stamp among the seven comment and CLI pages checked on 24 August 2026. The others range from 2025-09-24 to 2026-07-29, all newer than this brand-new page.

Which roles can delete a Vercel comment from the CLI?

The documentation does not say. Both the CLI page and the comments overview open with a "Permissions Required" block that names only the feature and lists no role, plan or token scope. Because the same page states that deletion cannot be undone, treat the command as unbounded and keep it out of automation.

Do I need to pass --yes in JSON mode?

The page gives two answers. It says JSON output does not prompt for missing input or confirmation, and it separately tells you to pass --yes in non-interactive or JSON mode for delete and for multi-thread resolve. Until that is clarified, pass --yes explicitly and check the exit code.

Is vercel comments available on the free plan?

Comments themselves are enabled by default on all preview deployments for all account plans, free of charge, according to the Vercel comments overview page. The CLI reference does not add a separate plan gate, though its permissions block is empty, so plan behaviour for the command specifically is undocumented.

What happens if one thread fails during a bulk resolve?

The reference page states that bulk operations continue after an individual thread fails and exit with a nonzero status if any operation fails. A partial result is therefore a documented outcome, and any script calling resolve or reopen across multiple threads must read the exit code rather than assume all threads changed state.

Should I install vercel@canary to get the new command?

No. The npm canary dist-tag for the vercel package resolved to 51.7.0 when checked on 24 August 2026, eight major versions behind latest at 59.5.0, and it predates the comments command entirely. Install a pinned version such as 59.5.0 instead. The package declares engines.node of 18 or later.

How eCorpIT can help

We build and audit CI pipelines that call vendor CLIs, and the failure mode above is one we check for by default: destructive subcommands with undocumented permissions, inconsistent confirmation flags, and no pinned version. Our senior engineering teams review your deployment and review tooling, pin the versions, and put an exit-code contract around every non-interactive call. Book a CI and deployment tooling review if vercel comments is about to enter your automation.

References

1. Manage Vercel Toolbar comments from the CLI, Vercel Changelog, 20 August 2026
2. vercel comments, Vercel CLI reference
3. Comments Overview, Vercel docs
4. Enabling Comments, Vercel docs
5. Managing Comments, Vercel docs
6. Comments Integrations, Vercel docs
7. Vercel Toolbar, Vercel docs
8. Vercel CLI overview and install paths, Vercel docs
9. vercel package registry metadata, npm
10. vercel package page, npm
11. vercel/vercel repository releases, GitHub
12. Sharing preview deployments with external collaborators, Vercel docs

Last updated: 24 August 2026.