A website login and a tool’s app session are separate. Sign in from the tool you are using and approve the browser request.
Sign in from each tool
- MCP
- Call sign_in, approve in the opened browser, then call sign_in again. Check whoami.
- CLI
- Run privatenote login and follow browser approval. Check privatenote whoami.
- Editor
- Run PrivateNote: Sign In from the command palette. Check PrivateNote: Show Account.
- Chrome
- Use Sign in in the popup and complete browser approval.
Signing out of one tool revokes its app session. It does not replace signing out of the website or another tool. Never share a tool’s session file.
Expiry presets
The tools accept 5m, 10m, 15m, 30m, 1h, 2h, 8h, 1d, 3d, 7d, 14d, 15d, and 30d. The token 24h is an alias of 1d. The default is 24h.
Server-side account limits still apply. Longer than three days requires a paid account. A client offering a duration does not override the account’s entitlement.
Burn after reading
Burn after reading defaults to true. Disabling it in these tools requests two reads, rather than unlimited access, and requires a paid account. For a read-once test, reveal the content once and then try to reveal it again.
Features requiring an account
- MCP file attachments require sign-in. File counts and sizes remain subject to account limits.
- MCP recipient verification, open notifications, and sent-note list/revoke require a paid signed-in account.
- Open notifications also require a verified sender email.
- Signed-in Business notes can use account reveal-page branding. The service resolves branding from the account; the model does not provide branding assets.
Recipient verification and passwords
A reveal password is a separate recipient requirement. Send it through a different channel from the link.
MCP recipient verification checks ownership of the configured recipientEmail before reveal. It is separate from sendRecipient, which identifies the delivery destination for approval. Setting a verification email does not deliver a message.