---
title: "Bot Screens are window-scoped work surfaces; per-Bot displays are an experimental opt-in"
version: "en"
---

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

# Bot Screens are window-scoped work surfaces; per-Bot displays are an experimental opt-in

> Status: Accepted

# Bot Screens are window-scoped work surfaces; per-Bot displays are an experimental opt-in

A **Bot Screen** starts as the windows one PersonaBot owns on the shared desktop: the provider scopes observation and action to that set, attributes every action in the audit, and — when the Human watches — places those windows on their own X11 workspace so the viewer can switch between Bots. **Per-PersonaBot virtual displays** (each Bot its own `Xvfb :N`, driver, and browser) are an experimental opt-in in Bot settings, not the default.

Measured on 2026-09-28: XFCE unmaps windows on non-current workspaces, so a Bot whose workspace is not displayed cannot be observed or verified — the workspace model is a **sequential** work surface, not a parallel one. That boundary is why per-Bot displays exist: they are the only way several Bots work in parallel, matching the reference product's "each Bot gets its own screen". The cost playbook for that mode is recorded in `docs/research/2026-09-28-multi-display-cost-reduction.md`: cap the primary `Xvfb` geometry (measured ~~490 MB, once; the actual resolution then continues to drive encoding CPU and screenshot size, with 1280×800 the preferred default and 1024×768 the floor), a light window manager per display instead of XFCE (~~-280 MB per Bot), lazy display+driver creation with idle reaping (~50 MB idle floor), one Chromium per Bot (hard constraint, ~200–230 MB each: windows cannot span X displays and one `user-data-dir` admits one process), a single Selkies that follows the watched display, `Xvfb` without GLX, and headless Chromium for non-visual work.

One decision is deliberately left to the experimental design: shared logins. Per-Bot Chrome profiles do not share cookies, so the mode must either sync sessions (for example through CDP) or abandon the shared-login semantics that both the container default and the reference product provide; silently breaking shared logins is not acceptable.

## Why

- The window-scoped surface costs nothing new, delivers ownership, audit attribution, and a Human-visible organization immediately, and is required by both modes anyway.
- The measured unmap boundary makes "workspaces give parallel work" false; without that fact the container would silently fail multi-Bot expectations.
- Per-Bot displays cost roughly 0.4–0.8 GB per active Bot while the container already runs near its 2 GB default, so they must be a knowing Human choice with a budget, not a default.
- The login trade-off changes product semantics; it deserves its own decision rather than being inherited from a display optimization.

## Considered options

- **Per-Bot displays by default** — rejected: cost and the shared-login trade-off are too large for a default.
- **Window scoping only, never displays** — rejected: the product model includes parallel per-Bot screens; the path stays recorded with its playbook.
- **Browser contexts (CDP) as the screen model** — rejected: isolates only the browser; a Bot Screen covers any application.

## Consequences

- The container stack gains what window scoping needs (workspace tooling or the driver's own space model) now, and the per-Bot display path is gated behind an experimental switch.
- Bot settings gains the experimental toggle with its memory budget surfaced; the container default memory becomes a follow-up decision.
- The C-mode login strategy is an open item to settle in the experimental design.
- The research playbook is the cost baseline; new measurements replace estimates there, not in this record.

Source: https://botharness.ai/dev/adr/0083-bot-screens-are-window-scoped-first-displays-experimental/index.mdx