I checked what you can do with the pnpm access command added in pnpm 11.11.0

Hey! I'm Yuji Nishimura from the Operations team!

In pnpm 11.11.0, released in July 2026, the pnpm access command was added. Following the same structure as npm's access command, it's a command that lets you manage package visibility and team access on the registry from the CLI.

However, as of the time of writing, the pnpm official documentation does not yet have a page for pnpm access. So, using the release notes and the implementation PR as primary sources, I've organized what I found while actually running it locally on 11.11.0. Note that the same 11.11.0 also includes a security fix (path traversal protection during dependency installation), but this article focuses solely on the new pnpm access command.

What you can do with pnpm access

pnpm access is a command for managing "who can do what" with packages on the npm registry. There are three main areas it covers:

• Visibility: Getting and changing a package's public / private (restricted) state
• 2FA requirement level: Setting whether 2FA is required per package, such as during publish
• Team access: Granting or revoking read-only / read-write permissions to organization teams (scope:team)

npm has had npm access for a while, and pnpm access follows the same subcommand structure (implemented in PR #12816). In pnpm, since 11.0, there has been an ongoing trend of bringing registry operation commands natively into pnpm itself — stopping delegation to the npm CLI for commands like whoami, ping, and dist-tag and replacing them with native implementations — and pnpm access is one more step in that direction.

Trying it out

Environment

• pnpm 11.11.0
• Node.js v22.22.2 / corepack 0.34.6
• macOS

Using corepack, the version is pinned by specifying pnpm@11.11.0 in the packageManager field of package.json.

1. Checking the list of subcommands

Running pnpm access --help shows the following subcommands:

$ pnpm access --help
Usage: pnpm access list packages [<user>|<scope>|<scope:team>]
       pnpm access list collaborators [<package> [<user>]]
       pnpm access get status [<package>]
       pnpm access set status=public|private [<package>]
       pnpm access set mfa=none|publish|automation [<package>]
       pnpm access grant <read-only|read-write> <scope:team> [<package>]
       pnpm access revoke <scope:team> [<package>]

In the options section of --help, --registry <url> / --json / --otp <code> are listed as common options.

2. Running read operations

Since write operations (set / grant / revoke) would change settings on actual packages in the registry, I only ran read operations this time. When executed against a public package without authentication, the results were as follows:

$ pnpm access get status is-positive
[ERR_PNPM_REGISTRY_ERROR] Failed to get status of package:
405 Method Not Allowed. GET is not allowed

$ pnpm access list packages
[ERR_PNPM_PACKAGE_NOT_FOUND] Package not found in registry. /-/-/package does not exist

Both resulted in errors, but the commands did reach the registry, and the registry's responses were converted into pnpm error codes. The first 405 Method Not Allowed indicates that the access endpoint does not accept GET requests. This suggests the command is not intended for casually browsing package status without authentication.

In other words, pnpm access is not a command for "browsing metadata of public packages." It's positioned as a command for managing permissions on scoped packages you own or within your organization, used after authenticating with something like pnpm login. Note that behavior with authentication and write operations were not tested this time. Based on the --help output, when running write operations with an account that has 2FA enabled, you're expected to pass a one-time password via --otp.

Current caveats

Official documentation not yet available (as of 2026/7/12)

Differences from npm access and shared constraints

There is one difference from npm access, and one constraint shared with npm.

The npm access documentation states that omitting the package name causes the command to act on the package in the current directory. However, when running get status without a package name in pnpm 11.11.0, the following error occurred:

$ pnpm access get status
[ERR_PNPM_ACCESS_GET_STATUS_PACKAGE_REQUIRED] Package name is required (e.g., pnpm access get status @scope/pkg)

Also, unscoped packages are always public by npm registry specification (the npm access documentation states "Unscoped packages are always public."). Therefore, you cannot make an unscoped package private using set status. This is a constraint shared with npm.

When can it be used?

Based on what I tested, it seems useful in the following scenarios:

• Maintainers of scoped packages: When you want to manage the visibility of restricted packages or 2FA requirements at publish time from the command line
• Organization administrators: When you want to handle granting and revoking team-level access via CLI rather than the Web UI
• pnpm users who also use the npm CLI: When you want to consolidate registry permission operations, previously dependent on the npm CLI, into pnpm

On the other hand, if you just want to view package metadata, pnpm view, which requires no authentication, remains an option.

Even with just --help, you can understand the subcommand structure, so if you've used npm access before, the migration effort should be minimal.

Summary

• In pnpm 11.11.0, pnpm access was added for managing package visibility, 2FA requirements, and team access on the registry (following the same subcommand structure as npm access)

• Since the official documentation is not yet published as of the time of writing (2026/7/12), checking the implementation PR and the --help output is the most reliable approach for details

I hope this is helpful to someone.

Reference links:

• pnpm 11.11.0 release notes
• PR #12816: feat(cli): implement the access command for both pnpm and pacquet
• npm access documentation