Open the exact current Oysterun Host URL supplied by its owner in a private browser profile you control. Sign in through the password-only web form, then verify both the Sessions destination and its visible connection state before you begin work.

1. Prepare the exact Host access details

You need an exact current Host URL and the current Host password from the person who owns or administers that Host. Open the URL in a browser profile that you control and do not share.

2. Confirm the password-only starting screen

Complete signed-out This Host screen with Oysterun, the empty Password field's eight-bullet placeholder, Open Oysterun, and no username field.
Visible checkpoint: the signed-out This Host card shows Oysterun, one empty Password field (the eight bullets are its placeholder), Open Oysterun, and no username field.

The signed-out Host screen has the eyebrow This Host, the heading Oysterun, one field labeled Password, and the action Open Oysterun.

  1. Check the browser origin against the exact URL you intended to open.
  2. Confirm that there is no username field. The normal public web form asks only for Password.
  3. Before typing, make sure screen sharing and screenshot capture are off if they could expose what you enter.

Checkpoint: the visible page is the password-only Oysterun card on the expected origin. If it asks for a username, shows an unrelated identity provider, or has a different origin, do not enter the password.

3. Sign in once

  1. Enter the current Host password in Password.
  2. Choose Open Oysterun once.
  3. While authentication is in progress, expect the button to read Opening…. You may also see Opening Oysterun... and then Loading sessions....
  4. Wait for the authenticated page instead of submitting the password repeatedly.

A successful sign-in creates an authenticated session in this local browser profile. Keep the profile private: do not export its storage, copy its token, or use it in public evidence.

If the attempt is rejected, the same card shows Invalid credentials. Clear the field before the one bounded retry described below; the screenshot is a recovery checkpoint, not an instruction to reproduce a failed login.

Complete This Host sign-in card showing Invalid credentials, an empty Password field with its eight-bullet placeholder, and Open Oysterun ready for one safe retry.
Visible recovery checkpoint: Invalid credentials appears in the full sign-in context. The empty Password field exposes no entered credential, and Open Oysterun remains the normal action for one bounded retry.

4. Verify the Sessions destination and connection

  1. Confirm that the authenticated page title is Sessions.
  2. Outside an open Session chat, find the connection indicator and confirm that it reads Connected.
  3. Read the qualifier beside it: Direct Host, Managed Endpoint, or Managed WebRTC.
  4. Confirm that the origin and qualifier match the access path you were given. The qualifier describes the active transport; it is not a second login or a different user identity, and it does not make an unexpected origin safe.
Complete authenticated Sessions page with page controls, empty Session-list context, application navigation, Connected, and the Direct Host qualifier visible together.
Visible completion checkpoint: the complete Sessions surface shows its page and navigation context, an empty private-safe list, and the real Connected · Direct Host state together.

5. Understand temporary connection states

Connected

The Host is reachable through the displayed transport qualifier. This is the ready state.

Reconnecting...

The browser detected a sustained interruption and is retrying. Wait for the same indicator to return to Connected; do not sign in again while the authenticated page is still retrying.

Connection Lost. Still retrying.

The interruption has continued, but Oysterun is still attempting recovery. Use the bounded recovery below rather than changing Host settings or restarting services.

A very brief interruption can recover before a warning is shown. Connection status is event-driven, so this journey does not require an internal health URL or repeated status checks.

Recover safely and know when to stop

Safe stop: do not start or resume a Session until the intended Sessions page and Connected state are both visible.