Work sessions overview

A work session is a time-bound, approved grant of access to one or more servers. Instead of connecting to a server directly, you request a session that says which servers you need, what you want to do, and for how long. Once approved, you can launch the tools you requested—a browser terminal, file transfer, the code editor, command execution, and more—until the session expires.

Why work sessions?

Work sessions replace direct, always-on server access with access that is requested, reviewed, and recorded:

  • Least privilege — you only get the servers, features, and time window you ask for.
  • Approval built in — a user with the Superuser role reviews each request before access is granted.
  • Time-bound — sessions expire automatically, so access never lingers.
  • Fully audited — every session, the features used, and the activity inside it are recorded.
  • One request, many tools — a single session can cover the terminal, file transfer, editor, command execution, and privilege elevation across several servers.

How it works

Working with a server follows four stages:

  1. Request — From a server or the Sessions page, click Connect and choose the target servers, the features you need, a purpose, and a duration. See Request a session.
  2. Approval — Your request enters the Pending state. A user with the Superuser role approves or rejects it. You can cancel a pending request at any time.
  3. Active — Once approved, the session becomes Active. Open the session and Launch the features you requested, or attach from the CLI.
  4. End — The session ends when it reaches its expiry, or when you terminate it early. Terminating closes all connections immediately.

See Use a session for launching features, extending, and ending a session.

Sessions in an advisory workspace

When a workspace’s execution control is set to Advisory, stage 2 doesn’t apply. A session is admitted without review and becomes Active immediately—or Approved until a scheduled start time arrives—for every requester, including a session requested by an AI agent, which always waits for a human decision under Enforce.

Nothing else about the session changes. It still covers only the servers and features you asked for, it still expires on its own, and it’s still recorded end to end. The rules about which system account a session may run as are unchanged.

What changes inside the session is when judgment happens, not whether it happens. Commands are judged after they run instead of before, and carry the Advisory verification status in Commands and on the session timeline. sudo still needs its own authority and a recent verification—advisory removes the risk gate, not the requirement to be allowed.

An amber Advisory chip beside the workspace name in the top bar tells you a workspace is in this posture.

Key concepts

Features (scopes): the set of capabilities you request for a session—web terminal, file transfer, command execution, port forwarding, code editor, and privilege elevation. See Session features.

Duration: how long the session stays usable. You pick a preset (1, 2, or 4 hours) or a custom length. Your workspace sets a maximum allowed duration.

Status: where the session is in its lifecycle—Pending, Approved, Active, Completed, Expired, Rejected, Cancelled, or Revoked. See Session lifecycle.

Launch vs CLI: how a feature is used. Some open directly in your browser with a Launch button (web terminal, file transfer, code editor); others are used from the Alpacon CLI after attaching to the session (command execution, port forwarding).

Where to find work sessions

Open Sessions under the Access group in the sidebar to see your sessions and create new ones. You can also start a session straight from a server—click Connect on any server card or detail page, and the server is pre-selected in the request form.

Getting started

  1. Request a session — choose servers, features, and duration
  2. Session features — what each feature lets you do
  3. Use a session — launch tools, extend, and end a session
Last updated: