outlive is pre-1.0. Only the latest 0.x release receives security fixes.

Please report vulnerabilities privately. Open a private security advisory on GitHub for this repository (Security → Advisories → "Report a vulnerability"). Do not open a public issue for a suspected vulnerability.

We aim to acknowledge a report within a few working days and to keep you updated as we work on a fix. Please give us a reasonable window to release a patch before any public disclosure.

outlive keeps a long automation running across Solari cloud browser sessions that end on their own after about ten minutes. To do that it holds a checkpoint: the storageState of the browser context — cookies, including HttpOnly session cookies, and localStorage — plus the current URL.

• A checkpoint is a credential. Anyone holding one can resume the session it came from, for as long as those cookies are valid.

• outlive keeps it in memory only. It is never written to disk, never logged, never included in the wide event and never sent anywhere except into the replacement browser context. It lives as long as the outlive() call and is dropped with it — including from any ctx the caller kept, whose checkpoint() releases its reference when the entry is retired. If you persist a checkpoint yourself, protect it like a password.

• URLs are logged as hostnames, never in full — both the fields outlive authors (resumeHost, host) and any URL it finds inside someone else's text. A Solari preview URL carries a bearer pt_token in its query string, the path can carry a record id, and the default logger writes warnings to stderr, so the whole tail after the host is dropped.

• Text outlive did not write is scanned before it is logged, and clipped to 300 characters. What the scan removes: every URL's path, query and fragment; name=value pairs whose name is one of token, key, secret, session, sid, auth, password or bearer; and the Solari preview token in every form it is written.

  Also Bearer <value> and Basic <value>, the Authorization header shape.

  This is a net, not a guarantee. error is text your task or the SDK produced, and outlive cannot know every shape a secret takes. If your own error messages may contain credentials that do not look like any of the above, that is between you and your log sink — send outlive's output somewhere you trust, and do not turn on full diagnostics there.

• diagnostics: "full" turns both off. It emits raw URLs and raw messages. It is opt-in, it is never the default, and it is the only way to get them.

• The wide event carries no secret outlive itself holds. No API key, no cookie values, no checkpoint, no URL — only counters, timings, an error's name and code, and its message after the scan above.

• Your SOLARI_API_KEY is yours. outlive never reads it: you construct the Solari client and pass it in.

• Every browser outlive launches, outlive closes, including on the failure paths, so a crashed run does not leave a live session holding your data. When close() fails, outlive retries the session release through the control plane; if that fails too it reports releaseFailed on the wide event and logs an error, rather than reporting a clean run over a live session.

In-scope reports include: a checkpoint leaking into a log, an event or an error message; a checkpoint outliving the call that created it; a browser session that is not released on some path; and dependency issues in the published tarball. Out of scope: the fact that a task is re-entered after a session death — that is the documented contract, and a task with side effects has to be written for it.