Definition#

In production runs the executor retains the authenticated state a completed login produced; a later health action confirms the stored session remained usable rather than logging in again. Locally, the CLI exposes the same idea through the browser profile directory: pass --user-data-dir <dir> to weles open to reuse a persistent profile across navigations.

Imported session references stay on one host#

An imported trajectory can retain browser, os, locale, headless, proxy, and session_label configuration. Weles imports the label, not the browser profile or cookies behind it, and binds the new draft to one exact managed worker hostname. If that draft is later reviewed and activated, saved-task execution refuses it on a different OS hostname before starting a browser.

The observed page receives the action#

Since Weles 0.7.7, the browser loop uses the same active page for its observation, screenshot and dispatched action. When sign-in opens a popup, the session follows that page; if it closes, the loop selects a surviving page in the same browser context.

Earlier runs could observe a popup while still sending actions to the originating tab. Inspect the actual action results and final page before repeating a failed sign-in. Stored cookies or a successful credential fill alone do not prove that the authenticated session works.

Where saved sessions are kept#

Saved cookies for every service live in one session store, kept with Weles's other credentials: on a machine running Skarbiec it is the Weles setting browser_sessions in the vault; on a machine without Skarbiec, where WELES_CREDENTIALS_FILE names the owner-only credentials file, it is that file's item weles-browser-sessions, field sessions_json. No file under the home directory holds saved cookies, and a ~/.weles/sessions.json left by an earlier release is not read; sign in again to save a session where it now belongs, then delete that file. A store that holds nothing yet holds no sessions. One that holds something other than a map of session labels to cookie lists, or a credentials-file field that is not JSON, is refused naming where it is ('Skarbiec setting browser_sessions does not map session labels to cookie lists'); nothing rewrites it while it cannot be read, so no other service's saved session is lost.

FetchAccountValue (the account-value task) is given the browser's operating system, the directory its learned routes are kept in and, when it goes through one, its proxy; a missing one is refused by name ('FetchAccountValue needs osTarget: it is stated by the caller, never assumed'). A learned route that cannot be read or is not a route, and a saved session that cannot be read or written, end the run with the path and cause ('trajectory cache <path> cannot be read: …', '… is not a learned route: …'). A login page met without a granted username or password ends the run naming the missing field, and a login that does not reach the account names the page it stopped on. A route that cannot be learned after the value was read is logged with its cause and the value is still returned.

Credentials never enter prompts or logs#

Sessions authenticate through scoped Skarbiec grants. API keys and passwords move through the Skarbiec lifecycle — acquire, adopt, rotate, reset, verify — without plaintext ever touching a prompt or a log. Workflow input carries opaque credentialRefs only; their resolution belongs to the executor's secret boundary.