A package published from a workflow is linked to its repository and inherits the repository's access: people who can write to BookNest can publish new versions, and its workflows can read the package. A package created any other way under a personal account starts private. Visibility is changed on the package's settings page, and one way only: "once you make a package public, you cannot make it private again." Asking anonymously shows what the public sees of the new package:
for u in github.com/binarybehemoth/booknest/pkgs/npm/booknest-catalog \
npm.pkg.github.com/@binarybehemoth%2fbooknest-catalog; do
curl -s -o /dev/null -w "%{http_code} $u\n" "https://$u"; done200 github.com/binarybehemoth/booknest/pkgs/npm/booknest-catalog 401 npm.pkg.github.com/@binarybehemoth%2fbooknest-catalog
The page is public, like the repository, but the npm registry 2,036 still answers 401: GitHub 29 's npm registry wants a token even for public packages, so every consumer needs a classic token with read:packages, or GITHUB_TOKEN inside Actions. That friction is why most public libraries still publish to npmjs.com and use GitHub Packages 29 for internal ones.
GitHub never deletes package versions on its own. Delete them on the package page or through the REST API (package deletion needs a classic token), or in a scheduled workflow with actions/delete-package-versions (https://github.com/actions/delete-package-versions 445 ) v5, which keeps the newest min-versions-to-keep versions or removes untagged ones. A deleted package can be restored for 30 days, and a public package with a version downloaded more than 5,000 times cannot be deleted without GitHub Support, since other projects depend on it.