--- title: "Work session features" description: "Choose features for an Alpacon work session. Compare terminal, file transfer, command, port forwarding, editor, and sudo access before requesting a session." --- > Full documentation index: https://docs.alpacax.com/llms.txt # Work session features # Work session features Session features include terminal access, file transfer, command execution, port forwarding, code editing, and sudo. ## How session features work When you [request a session](/use/work-sessions/create/), you choose which features it grants. Each feature unlocks a specific way to work with the servers in the session. You only get the features you request and that are approved. Features are used in one of two ways: - **Web interface**: launches directly in your browser from the session's detail page. - **CLI**: used from the [Alpacon CLI](/reference/cli/) after you attach to the session. ## Available features ### Web terminal Run commands on a server through a browser terminal. On the session's **Session** tab, click **Terminal** on that server. You can also open a terminal from the CLI. ``` $ alpacon websh SERVER ``` See [Terminal access (Websh)](/use/work-sessions/terminal/) and the [`alpacon websh`](/reference/cli/websh/) CLI reference. ### File transfer Transfer files to and from servers, including drag and drop in the browser. On the session's **Session** tab, click **Files** on that server. You can also transfer files from the CLI. ``` $ alpacon cp SERVER:/path/to/remote ./local/ ``` See [File management (WebFTP)](/use/work-sessions/files/) and the [`alpacon cp`](/reference/cli/cp/) and [`alpacon edit`](/reference/cli/edit/) CLI references. ### Execute commands Run commands across one or more servers from the command line. Used from the CLI. ``` $ alpacon exec SERVER -- COMMAND ``` See the [`alpacon exec`](/reference/cli/exec/) CLI reference for full usage and flags. ### Port forwarding Securely forward a server port to your local machine. Used from the CLI. ``` $ alpacon tunnel SERVER -l LOCAL -r REMOTE ``` See the [`alpacon tunnel`](/reference/cli/tunnel/) CLI reference for full usage and flags. Port forwarding works only on servers with the **Tunnel** setting turned on. See [Tunnel and code editor](/use/servers/manage/#tunnel-and-code-editor). ### Code editor Edit files on a server directly in a browser-based code editor. On the session's **Session** tab, click **Editor** on that server. The editor works only on servers with the **Code editor** setting turned on. See [Tunnel and code editor](/use/servers/manage/#tunnel-and-code-editor). If the setting is off, that server's **Editor** action explains why it cannot open. See [Code editor](/use/work-sessions/editor/). ### Privilege elevation (sudo) Perform actions with elevated (sudo) privileges within the session's other features. This is not launched on its own—it grants elevated permissions to the terminal, file transfer, and other features you use. Including it in the session is only the first step: it has to be requested and approved like any other feature. Each time you then use sudo, the action is checked again at that moment. Depending on your workspace's approval policy, it's either cleared automatically for low-risk actions or held for a person to approve, and it may prompt for MFA. An approval stays valid for a limited time window, and every sudo action is recorded in the audit trail. **A command a person approved covers its own sudo.** When a command is held for approval and a person approves it, that approval also covers the `sudo` written in the approved line. The elevation runs without a second sudo approval and is not refused for its risk level, Critical included. The approval covers only what the approver saw, during that command's own run. A few forms are still checked on their own and can ask for a second approval or be refused: `sudo sh -c '…'` with a script that contains spaces, `sudo -u` with an account other than `root`, and a `sudo` reached indirectly, such as through a script or `xargs`. An approval policy your workspace wrote to deny the command, or to require more than one approver, still applies. **A command nobody approved** is judged on the stricter of its overall risk level and the level AI verification rejected it at. A command rejected as Critical is refused, and one rejected as High waits for an approval, even when its overall level reads lower. In a workspace whose [execution control](/use/policies/server-access/) is set to **Advisory**, risk never holds a sudo action—it's recorded in [Privilege elevation](/use/audit/events/sudo/) as **Advisory (not gated)** instead. Everything else about sudo is unchanged: you still need the authority to run the command, and MFA can still be asked for. This describes sudo inside a work session. A pipeline running under a service token is decided differently—it is never held for a person and never prompts for MFA. See [Command patterns and sudo](/use/iam/applications/service-tokens/command-patterns/#what-happens-when-a-token-runs-sudo). See [sudo with MFA](/use/work-sessions/terminal/sudo-with-mfa/). ## Feature summary | Feature | How it's used | CLI command | | --- | --- | --- | | Web terminal | Browser + CLI | `alpacon websh SERVER` | | File transfer | Browser + CLI | `alpacon cp SERVER:/remote ./local/` | | Execute commands | CLI | `alpacon exec SERVER -- COMMAND` | | Port forwarding | CLI | `alpacon tunnel SERVER -l LOCAL -r REMOTE` | | Code editor | Browser | — | | Privilege elevation | Modifier (no launch) | — | ## Changing features after approval The session owner or a Superuser can change the features on an approved or active session. Updating features may require another approval before the change takes effect. See [Use a session](/use/work-sessions/detail/). ## Related docs - [Request a session](/use/work-sessions/create/) - [Use a session](/use/work-sessions/detail/) - [CLI reference](/reference/cli/) Source: https://docs.alpacax.com/reference/work-session-features/