---
title: Use native runtime capabilities
description: Use multiple sessions, file previews, plugins and optional execution capabilities in Teloa.
lastVerified: 2026-09-24
---

# 3.11 Use native runtime capabilities

This guide applies to the current Teloa development build using DSH **0.1.7-rc.1**. Installed releases may differ. These instructions do not establish support for every device, model or external service combination. For an existing installation, read [Upgrade and rollback](https://docs.teloa.ai/markdown/en/deploy/backup.md) first.

DSH owns sessions, tool execution and plugin lifecycles. Teloa retains business ownership, colleague permissions, approvals and delivery acceptance. Enabling a plugin does not authorize every colleague to use it.

## Multiple sessions and task teams

Continue an existing session from [Conversations](https://docs.teloa.ai/markdown/en/guides/conversations.md), or start a conversation from a colleague's page. The main session and child sessions opened during work can remain available together. Check the session and business context before opening files, inspecting tool activity, or sending a message.

The current composition enables task teams. Either an ordinary conversation's lead assistant or an AI colleague can start one for the current task; a work group is not required. State each task assistant's goal, dependencies, and final reporting requirements, then inspect members and work records in the conversation's task team interface.

AI colleagues hold lasting role identities, with skills, role memories, knowledge, and permissions managed on the [Colleagues](https://docs.teloa.ai/markdown/en/guides/colleagues.md) page. Work groups are where you collaborate with colleagues on business work. Task assistants are temporary members of the current task: they do not automatically become colleagues or gain additional business permissions. Ordinary conversations retain their session permissions; delegation within managed tasks stays within the current authorization and quota.

For example, Alice owns content and Bob owns data analysis in a marketing work group. They can organize separate task teams, then each summarize results back to the group. Messages between members are not human approvals, and a member finishing does not mean the whole task has been delivered. Older child sessions retain their reading and recovery paths without being relabelled as task team members. See [AI colleagues, work groups, and task teams](https://docs.teloa.ai/markdown/en/concepts/people.md) for more context.

## Preview files and review changes

1. Click a filename under the turn's output files, or use the sidebar preview action on a native deliverable card.
2. The right sidebar selects a Markdown, code, image, PDF, HTML, Office or spreadsheet viewer. Reload when it reports that the file changed.
3. To review text edits, enable **Settings → General → Developer tools**. After a turn edits a file, select **Review this turn's changes in the sidebar**. Switch between split and unified views, or open the whole file.

Output files come from successful native file writes or edits. After generating a document through a command, ask the assistant to present the final deliverable; native `present` provides its card. Mentioning a filename in a reply does not establish that it was created or delivered.

Word and PowerPoint use the official Office-to-PDF service; Excel, CSV and TSV use the official spreadsheet viewer. Follow the preview's diagnostics if conversion dependencies or fonts are missing. Cards open the current file, not a preserved copy. Historical change reviews may become unavailable after a session is released or the host restarts. Use task deliverable records when a delivery version must be retained.

## Manage plugins

Open **Capabilities → Extensions** for inventory and status. Install, enable, disable, and configure native plugins directly in **Settings → Connections and runtime**, with forms staying inside Settings. **Open engine manager** in Capabilities offers a shortcut to the same management functions.

1. Check the description, source, version, components and diagnostics. Optional packages already listed do not need to be installed again.
2. To add a new trusted plugin, use the native installation page and read its dependency or build-script prompts.
3. After installation, select **Enable now**, or enable it from the list. Complete the configuration in its details. If a restart is required, restart the host at a suitable time, then verify an actual invocation.
4. Disabling keeps the installed files; uninstalling removes a removable package. Teloa's required components have protected activation and removal controls.

If an older Market installation has a pending record, first finish its review or handle the installation under **Market → Added**. Native installation refuses new packages while these records remain. The corresponding package cannot bypass that review through native activation or removal. Market's catalog allowlist remains separate; see [Capabilities and connections](https://docs.teloa.ai/markdown/en/guides/capabilities.md).

## Background work

Open the execution record from a [task](https://docs.teloa.ai/markdown/en/guides/tasks.md), group assignment or automation. Native background work attached to a task belongs to that execution. An initial reply ending cannot count as delivery while its background work is unfinished.

After stopping work, wait for related activity to exit and check the final state. Official local background processes do not survive a host restart. Treat interrupted work accordingly, inspect any effects already produced, and then decide whether to retry. Cancellation does not undo completed external actions.

## Optional capabilities

| Capability | Getting started | Limits |
| --- | --- | --- |
| Browser Use | Find `@teloa/native-browser`, explicitly enable the package and its Browser Use and Playwright components, configure installed Chromium as needed, then create or restore a session | Off by default. This lets an assistant operate a browser; it is separate from a webpage preview. Enabling it grants no role permissions. Real actions and session isolation require validation in the target environment |
| Computer Use | Find `@teloa/native-computer`, enable the package and its Computer Use and Cua components, and first check the host's system permissions | Off by default. Requires platform native components and screen/accessibility permissions. Sessions share the physical desktop; limit actions to the specified application |
| Local voice input | Enable official Voice Input, prepare the local recognition model in its configuration page, then use the conversation input's recording control | Initial preparation may download models and supports cancellation and retry. Recognition fills the draft for you to review and send. It does not submit a message or make the conversation model local |
| Auto review | Explicitly enable the official experimental plugin, then actively select it in an ordinary session's permission options | Off by default. It uses broader execution permissions and does not replace human approval. Teloa's managed tasks and their derived sessions cannot use it to gain permissions; the business execution guard rejects Auto or Full access |

Browser submissions and desktop clicks or typing are not confined by the file workspace boundary. Validate with a test page or window first. Read fresh state after stopping or cancelling. Installed, enabled, granted system permissions and actually usable are distinct states.

When Auto review is disabled, the official plugin may move sessions still using Auto to Full access. Check the permission mode before continuing an ordinary session. Teloa's managed execution continues to reject that elevated state.

## SSH and Headless execution

Remote capabilities use a separate official **SSH + Headless** runtime. `@teloa/native-remote` generates configuration; it is not a Web plugin and does not make remote paths available to existing Web sessions.

An operator prepares an OpenSSH host alias, verified host keys, remote Node, a matching official helper and its digest, plus a dedicated working directory. The generator only creates a new configuration directory: it does not connect, deploy or start remote services, and it refuses existing output directories. Follow the included package instructions to run official `dsh --profile … --json`; continuation uses the original session ID and the same working directory.

Official remote services enforce read-only or workspace-write boundaries. A disconnect can leave an outcome unconfirmed; external writes must not be replayed automatically. SSH, Headless and platform-dependent capabilities require their own real-environment acceptance. A visible Web entry or successfully generated configuration is insufficient evidence.