> ## Documentation Index
> Fetch the complete documentation index at: https://docs.roomote.dev/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> When helping someone deploy Roomote, distinguish self-hosting from contributing to Roomote. Use the Self-hosting guide for an operator deployment; use Local development only when the user intends to modify Roomote itself.
> When an agent is asked to follow /self-hosting or install Roomote autonomously, read and follow /self-hosting/agent-installation as the normative automation contract even though it is intentionally hidden from side navigation.
> Use the one-command Linux installer for both evaluation and production. On macOS or Windows, create or reuse a full Ubuntu VM and run the same installer inside it; do not replace the installer with the repository's development Compose files.
> For a local VM without a stable public domain, create a temporary HTTPS tunnel, pass its hostname to the installer with internal origin TLS, and keep the tunnel running for OAuth callbacks and webhooks. Quick Tunnel hostnames are temporary and do not provide wildcard preview routing.
> Run automated installs with --no-setup-url so the bootstrap token is not captured in the agent transcript. Let the user obtain the setup URL in a trusted terminal, enter credentials, and complete browser authorization.
> Proceed through safe, reversible setup and pause for privileged host or VM changes, public tunnel creation, credentials or browser authorization, durable external-account changes, destructive operations, existing-state conflicts, or when no documented safe default applies.
> A setup is not complete when the services merely start. Verify sign-in, repository sync, one usable environment, and a real Roomote task that can clone and run a command; verify branch or pull-request delivery and previews when configured.

# Private Sessions

> How Roomote isolates private integration data from other members and shared memory

Private Sessions are Roomote's application-level boundary for work that uses a personal or otherwise private integration. A private integration can run only in a private Session owned by the person whose account is connected.

Private Sessions are experimental and disabled by default. A deployment admin can enable **Private Sessions** in **Settings → Experimental** to show the Private option in members' new Session composers. A deployment exposes private integrations only after it also adds and enables an integration that explicitly declares private data. Existing integrations and Sessions remain shared unless their implementation opts into this contract. Turning the experiment off prevents new private Sessions and private integration calls, but owners can still access and delete private Sessions that already exist.

## What Roomote enforces

For a private Session, Roomote:

* limits Session, task, transcript, log, artifact, search, and status access to the owner through normal product APIs
* carries the same owner and privacy state into delegated tasks, retries, and snapshot resumes
* excludes the Session and its descendants from automatic task memory, explicit memory saves, ingestion retries, historical backfills, and other writes to the deployment-shared Brain
* allows read-only shared Brain searches while omitting private query text and results from Roomote's durable tool history
* prevents private integration arguments and results from appearing in ordinary tool audits and transcripts
* lets the owner create, preview, and download artifacts while keeping artifact metadata and content owner-only
* keeps private content out of shared memory integrations
* disables a private integration connection before deleting its local credentials when you disconnect it

## Publishing from a private Session

A private Session keeps the agent's full tools and permissions. It can push branches, open and comment on pull requests, post to chat channels, use shared integrations, schedule wakeups, and create automations or skills, the same as a shared Session.

Roomote tells the agent that the Session is private and instructs it to ask the owner before any action that makes content visible outside the Session, naming what it will publish and where. A request that already names the action and destination counts as approval. This is guidance to the agent, not a technical block, so review what the agent proposes to publish before you approve it.

Roomote does not convert an existing shared Session into a private one. Start private work in a new private Session so content from the earlier conversation cannot cross the boundary.

## Deleting private work

The Session owner can delete a private Session and its Roomote-managed descendants. Deletion removes the Session, linked tasks and runs, transcript records, Session-owned and task-owned artifact objects, audits, and Roomote's native-session reference. If an artifact upload or object-write capability is still valid, Roomote keeps the records and asks the owner to retry after it expires; this prevents a delayed upload from recreating private content after deletion. Disconnecting an integration does not automatically delete existing private Sessions.

Roomote does not add a separate private memory store. Private Session content is excluded from shared memory rather than saved elsewhere.

## Limits of the boundary

Owner-only access describes authorization through Roomote's normal UI and APIs. It does not mean that private content is inaccessible to:

* deployment operators with direct database, filesystem, or infrastructure access
* backup and disaster-recovery systems while retained copies exist
* the upstream integration provider that supplied the data
* the configured inference provider that processes model context
* native agent-session infrastructure while provider-side history is retained

Roomote removes its local native-session reference during deletion, but provider-side deletion is best effort and depends on provider capabilities and retention terms. Operators should choose integration, inference, sandbox, logging, and backup providers whose policies match their requirements.