--- title: Clean Room (spawn a vanilla AI with none of your customizations — a control group) --- # Clean Room (spawn a vanilla AI with none of your customizations — a control group) ## What it is **Clean Room** is a special built-in project that appears in the projects sidebar (like **Session Search** or **Settings** — it isn't a folder on disk). Every session you start inside it spawns a **deliberately vanilla, "blank-context" AI** — a control group with **none of your customizations and none of Omniscio's added layers**. It exists to answer a single question: _what does the AI do on its own, with a pure blank slate?_ — a baseline to compare against your normal, fully-loaded sessions when you're debugging a behavior, testing a prompt, or checking whether a result comes from the model itself or from something Omniscio (or your own config) is injecting. It is **still real Claude Code** — the engine binary, its own base identity, and its own built-in tools stay. Clean Room strips the _added_ context around the engine; it does **not** drop you to a raw model API. Think of it as "the same agent, but with every layer you (and Omniscio) normally stack on top peeled away." ## Where to find it Clean Room sits in the projects sidebar as a built-in project, alongside **Session Search** and **Settings** — it is not a folder on disk, so there is nothing to create first. Open it like any other project and you land on its starting screen, where you pick an engine and press **Start a Clean Room session**. ### The starting screen Opening Clean Room (before you start a session) shows a **starting interface** that explains what it is — a short "what's removed vs. what stays" summary — and gives you an **engine picker** (defaults to Claude; offers the Claude-compatible vendors below when alternate harnesses are on) plus a **"Start a Clean Room session"** button. Starting opens a genuinely blank session on the chosen engine; the screen then steps aside for the normal chat. It is the same experience as the Automation Builder's landing. ## How it behaves ### When to use it - **Isolating a behavior.** You see an agent do something surprising and want to know if it's the model, your global rules, a project's instructions, a connected tool, or one of Omniscio's injected notes. Run the same prompt in Clean Room — if the behavior vanishes, something in your stack caused it; if it persists, it's the engine. - **Testing a prompt from scratch.** Evaluate how a prompt lands with zero priming — no house-style rules, no memory, no awareness notes nudging the answer. - **A clean-room baseline / control group.** Compare a vanilla run side-by-side with a normal session to measure what your customizations are actually contributing. - **Trying another engine bare.** Clean Room lets you pick the engine per session (see below), so you can see how DeepSeek / Kimi / GLM / MiniMax behave with nothing added, too. It is **not** the place to do real work — a Clean Room session has none of your rules, memory, skills, tools, or project context, so it won't follow your conventions or reach your integrations. Use a normal project session for that. ### Exactly what is stripped A Clean Room session starts with **none** of the following: - **Your global `~/.claude` rules and memory** — no `CLAUDE.md` house rules, no `MEMORY.md` index, no topic memory files. - **Skills** — no skills load at all: not your personal global skills, not project skills, not plugin skills. (Under the hood the session runs with the engine's own safe-mode, which disables every customization.) - **Project instructions** — no per-project `CLAUDE.md` / notes / instructions (there's no project folder to carry them anyway). - **Connected tools (MCP)** — no MCP servers are attached, so none of your integrations' tools are available to the agent. - **Omniscio's injected context** — every note Omniscio normally folds into the system prompt is omitted: the **awareness note** (that tells a session it's running inside Omniscio and how to reach its controls), **Plain Speak**, the conversation **markers**, the **publish / convert / download** helper shims, and the **question-widget formatting instruction** (the note that teaches the agent Omniscio's clickable-question format — it names the app, so a clean session never receives it, nor the shorter "ask in plain markdown" nudge). The agent is not told it's inside Omniscio and is not offered any of Omniscio's agent-callable helpers. - **Hooks** — a Clean Room session is fully **hook-free**; no PreToolUse / PostToolUse / any harness hooks fire. It also **starts in its own private room** — a fresh, empty per-session working folder. Each Clean Room session gets a **different** room, so one session can never see another's files, and the whole Clean Room area lives **outside the app's data folder**, so nothing sensitive (your database, sign-in, or notes) sits next to it. The folder is genuinely empty, but on its own that is not what keeps a clean session honest — the engine's native tools could otherwise read the rest of your disk. So a Clean Room session is **fenced to its room**: any file read or command that reaches OUTSIDE it is **blocked outright** — a flat refusal, not a one-click prompt you might approve by reflex (see "Known ceiling / caveats"). To give a session context, use **"Open room folder"** and drop files in — the agent can freely read anything you place INSIDE its room. ### Exactly what is kept - **The engine's own base identity** — it's still Claude Code (or the chosen engine's base agent). This is inherent to running the real engine binary and is what keeps it from being a raw model. - **The engine's own built-in tools** — the standard Claude Code toolset (read/write/bash/etc.) remains, because those ship with the engine itself. What's removed is your _added_ tooling (MCP) — not the engine's native tools. - **A working chat session** — you talk to it exactly like any other session; only the surrounding context is stripped. ### Known ceiling / caveats - **The engine's own base identity and tools always remain.** This is the definition of Clean Room, not a bug: it's a clean _Claude Code_ session, not a raw model. You cannot strip the engine's built-in identity or native tools from within Clean Room. - **How the isolation works (for the curious).** Your customizations are switched off by the engine's own **safe-mode** — a built-in mode that disables `CLAUDE.md`, memory, skills, plugins, hooks, MCP, custom commands/agents, and themes while sign-in and the native tools keep working. Omniscio's own injected layers are stripped separately by the app. So skills — global, project, or plugin — are genuinely gone, not just mostly. - **It's a control group with a filesystem fence, not a hard sandbox.** The engine's native tools are live and work freely INSIDE the session's room. Reaching OUTSIDE it — your real `~/.claude` config, another drive, another session's room, anywhere off this room — is **blocked outright**: a Clean Room session gets a flat refusal for any out-of-room file read or command (not the old one-click prompt), so a control group can't be walked out of its folder to reconstruct the context safe-mode stripped. It is still a control group, not a locked-down jail — the block closes the silent/accidental path AND the one-click-approve path, but a deliberately obfuscated shell script, or a path built at runtime inside an interpreter, can still reach disk. That residual is exactly why the Clean Room area is **relocated outside the app's data folder** — so even a clever escape lands somewhere with nothing sensitive next to it. "Clean" refers to the **context** (no customizations, no injected layers); the block + the relocation add a real reach limit on top. ### How a session's engine is chosen Clean Room has a **per-session engine picker** — it lives on the starting screen (above), and also on the normal session composer. When you start a session you choose which engine backs it; the picker **defaults to Claude**. In v1 it also supports the **Claude-compatible** models that run the same Claude Code binary against a vendor endpoint: **DeepSeek, Kimi, GLM, and MiniMax** (shown when alternate harnesses are enabled). Whichever you pick, the session is still a real Claude Code session with the vanilla, stripped context described above — only the underlying model changes. The choice is per session, so different Clean Room sessions can run different engines at the same time. ## Related Clean Room is easiest to understand by contrast. The awareness note it deliberately omits is described on the [session awareness](amc-session-awareness.md) page, the engine list its picker draws from is on the [AI providers](ai-providers.md) page, and the split between the engine's own built-in tools (kept here) and connected tool servers (stripped here) is on the [agent tools](agent-tools.md) page. - [amc-session-awareness.md](amc-session-awareness.md) — the awareness note that Clean Room deliberately omits (a normal session tells the agent it's inside Omniscio; a Clean Room session does not). - [ai-providers.md](ai-providers.md) — the engine/provider list; Clean Room's picker offers the Claude-compatible subset (DeepSeek, Kimi, GLM, MiniMax) alongside Claude in v1. - [agent-tools.md](agent-tools.md) — the engine's built-in tools (kept in Clean Room) vs. connected MCP tools (stripped).