Password protection

An optional shared password gates viewing an artifact. It's a perimeter, not an account system: anyone with the link and the password gets in, no sign-in required. Publish-token and owner holders bypass the gate entirely.

Set or clear

npx artifact-cafe@latest publish . --password espresso   # protect at publish
npx artifact-cafe@latest protect --password espresso      # set or update later
npx artifact-cafe@latest protect --off                    # remove

Or call the API directly, authorized by the publish token or the owner:

PUT /api/v1/artifacts/{artifactId}/protection
{ "password": "espresso" }   # set or update, 6-128 characters
{ "password": null }         # clear, artifact goes public

The password is hashed and never echoed back or logged.

Unlock

Reviewers unlock once:

POST /api/v1/artifacts/{artifactId}/unlock
{ "password": "espresso" }

A correct password sets a 30-day unlock cookie and returns { "unlocked": true }. A wrong one returns 401 invalid_password. The cookie is bound to the current password hash, so changing the password invalidates every outstanding unlock.

Enforcement on two origins

A protected artifact is gated everywhere it's reachable:

• The review shell's read APIs return 401 password_required without a valid unlock cookie, publish token, or owner session.
• The render origin ({slug}.artifactcafe.dev) serves a gate page until unlocked. Agents and headless clients can pass ?ac_pw=<password> instead of clicking through, and the shell hands the embedded iframe a signed ?ac_at=<token> so reviewers only unlock once, not once per surface.
• Link previews fall back to the locked card. The fetcher that builds a chat or timeline preview is anonymous, so it never reads your artifact's own description, image, or byline.

Protecting an artifact you have already shared takes effect immediately, but previews that chat platforms cached before you set the password are theirs to expire. The image behind such a card stops resolving right away, so a stale preview breaks rather than leaking.

Owner controls

Claimed owners set, rotate, or remove the password from the settings panel in the review shell, not just the API.

See also

CLI reference, HTTP API, and the password_required / invalid_password error codes.