> ## 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.

# Session secrets (prototype)

> Approve a short-lived credential for read-only requests to one trusted HTTPS origin.

<Warning>
  Session-secret agent tools are temporarily disabled while hosted credential
  access is being completed. Agents cannot prepare or discover Session approvals
  through these tools. Existing configured integrations remain available.
</Warning>

Session secrets are a paused prototype for letting a Roomote agent make a narrow
HTTP request without receiving the credential as a tool argument. They are not a
general-purpose credential vault or a replacement for [integrations](/integrations).

## While the prototype is paused

* agents cannot prepare, discover, or use Session-secret approvals;
* do not put API keys in chat, attachments, prompts, or task environment files;
* existing approvals remain stored and can be inspected or revoked from
  **Session secrets** in the Session header; and
* operator-configured [HTTP integrations](/integrations/http-integrations) remain
  available and continue to enforce their configured origins, methods, and paths.

For credential-backed agent work during the pause, ask a deployment operator to
configure an HTTP integration. Use a narrow origin and path policy and a
least-privilege credential.

## Security boundary

The secure form bypasses chat and does not store credentials in browser storage.
Its subtree is excluded from automatic capture and replay; server-side secret
routes exclude request telemetry. Do not put credentials in labels, origins,
paths or ordinary Session messages.

**The approved upstream receives the credential.** It can misuse any privileges
the credential grants, including write privileges even though this tool permits
only GET and HEAD. Some upstreams also perform side effects on GET. Use a
least-privilege, disposable, read-only credential and approve only a trusted
origin. An upstream can disclose partial values, hashes or arbitrarily
transformed data that this prototype cannot reliably recognize. Returned content
is visible to the agent and may enter the transcript. This is not a universal
secrecy or data-loss-prevention guarantee.