np

Summary , before publishing a package, prints a summary of the commits since the last release as part of its normal, interactive confirmation flow. Each commit's message is taken directly from and written to the terminal () with no filtering of control characters. Unlike a package's field (validated by 's strict naming rules) or a git branch/tag name (restricted by git's own ref-naming rules), a commit message has no character restrictions. Since running in a repository is exactly what a maintainer preparing a release does, any commit in the repository's history containing an embedded escape sequence in its message is written to the terminal and interpreted live during a routine release. POC (available upon request) Impact I validated this by creating a commit with a message containing a raw OSC title-set escape sequence, then running 's CLI entry point in that repository inside a tmux session, answering the initial confirmation prompt, and capturing the literal byte stream written to the pty via (which taps the raw bytes before tmux's own screen-buffer interpretation) up to the point the commit history renders, before any version selection or actual publish step, and inspecting it as a hex dump. The captured stream contained the exact injected sequence, unmodified, embedded in the commit message text, confirming it reaches the terminal without any stripping. I used a benign title-set marker specifically to confirm the sequence reaches output unstripped, rather than a more aggressive payload; the specific range of what an injected OSC/CSI sequence can do depends on the victim's terminal emulator and was not enumerated further. Suggested Fix Strip control characters, particularly the ESC byte, from a commit message before it's written to the terminal, the same way already rejects them in the package name field. I'd suggest filtering once in the commit-history builder in , since that's the point where it's rendered. I'm not including the exact reproduction steps in this issue, to give time to review and land a fix before the mechanics are public. The PoC is available on request. For your review and coordinated disclosure, Geo | GitHub.com/geo-chen

Description advertises support for several package managers, including pnpm. In our codebase we prefer to use pnpm, and would like to use it exclusively so that tooling is consistent across developer's machines. However, appears unable to run successfully with 's configured to only allow pnpm. Steps to reproduce 1. Have this in your : 2. Run Expected behavior I would expect the release to be able to run successfully. Instead, fails with while trying to execute internally. Environment np - v11.2.1, which is not the latest, though I don't see a fix for this in the release notes for v11.2.2 or v12.0.0, and Claude claims to have verified that the v12.0.0 codebase still contains this bug Node.js - 24.18.0 npm - n/a, that's the point pnpm - 11.15.1 Git - 2.54.0 OS - MacOS 26.2

Fixes #794