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 page, the engine list its picker draws from is on the AI providers 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 page.

• 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 — the engine/provider list; Clean Room's picker offers the Claude-compatible subset (DeepSeek, Kimi, GLM, MiniMax) alongside Claude in v1.
• agent-tools.md — the engine's built-in tools (kept in Clean Room) vs. connected MCP tools (stripped).