| name | ardoise |
| allowed-tools | ["Bash","Read","Write"] |
| description | Spawns an isolated Claude with no CLAUDE.md, no skills, no hooks, no plugin context — only training weights and built-in skills. INVOKE BEFORE running evals, design research, cold critique, baseline comparisons, or testing plugin installs as a fresh user would experience them. Triggers on 'blank slate claude', 'fresh claude', 'isolated claude', 'naive claude', 'test plugin install', 'out of box claude', 'ardoise'. (user)
|
Ardoise
Run Claude on a blank slate. The spawned Claude sees only its training weights and built-in skills — no CLAUDE.md, no custom skills, no hooks, no plugins, no project context. Like a restaurant's ardoise wiped clean.
Two modes:
- Interactive (default) — opens Claude's TUI as a fresh user would see it. For manual testing: plugin installs, onboarding flows, "what does a new user experience?"
- Print (
-p) — runs claude -p for automated/scripted use. For surveys, evals, cold critique.
When to Use
- Plugin testing — does
claude plugin install work for someone with a default ~/.claude?
- Design research — what verbs, patterns, or names would a Claude naturally produce?
- Skill evaluation — does a naive Claude understand a SKILL.md on first read?
- Eval baselines — "without skill" control group for A/B testing
- Isolation testing — verify a prompt works without your ecosystem's context
- Cold critique — get feedback uncoloured by your conventions
When NOT to Use
- Security sandboxing — this is context isolation, not filesystem/process isolation. The spawned Claude can still read host files if it knows the paths. Use containers for security.
- Testing your skills work — you want context loaded for that, not stripped
How It Works
Three mechanisms, all cross-platform (POSIX):
| Mechanism | What it blocks |
|---|
env -i | All inherited env vars including CLAUDECODE=1 (nesting detection) — except Vertex auth (project/region/ADC) when CLAUDE_CODE_USE_VERTEX=1 |
HOME=<tmpdir> with stripped claude.json + credentials only | CLAUDE.md, settings.json, hooks, skills, plugins, MCP config |
cd /tmp (or chosen dir) | Project CLAUDE.md, git repo context, local .claude/ directories |
Additional env vars suppress noise:
| Var | Effect |
|---|
CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 | No survey popups |
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 | No telemetry |
CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 | No auto memory files |
ENABLE_CLAUDEAI_MCP_SERVERS=false | No built-in Gmail/Calendar MCP |
The claude.json is copied from the real one (preserving onboarding state and feature flags) but stripped of project data, skill usage, and marketplace auto-install.
Usage
The script lives in the trousse plugin. Resolve the path:
SCRIPT="${CLAUDE_PLUGIN_ROOT}/scripts/ardoise.sh"
[ -x "$SCRIPT" ] || SCRIPT=$(find ~/.claude/plugins/cache -path "*/trousse/*/scripts/ardoise.sh" 2>/dev/null | sort -r | head -1)
The fallback uses sort -r | head -1 to prefer the highest-versioned cached copy when multiple are present.
Interactive mode (default)
"$SCRIPT"
"$SCRIPT" ~/some/project
Opens Claude's interactive TUI. You type commands yourself — claude plugin install, /doctor, whatever you want to test manually.
Print mode
"$SCRIPT" -p "What is the best way to structure a CLI?"
"$SCRIPT" -p --max-turns 1 "Reply with only: hello"
echo "Design a work tracker" | "$SCRIPT" -p --stdin --max-turns 1
Persistent HOME (multi-step tests)
Default runs use a fresh temp HOME, deleted on exit. For a sequence that must share state across invocations — plugin marketplace add → plugin install → -p verify — use a named HOME:
"$SCRIPT" --home ~/ardoise-sbx ~/some/project
"$SCRIPT" --home ~/ardoise-sbx -p "verify it loaded"
--home DIR creates the dir if missing, seeds it once (auth + stripped config), and never auto-deletes it — so plugins/marketplaces added in one invocation survive to the next. --keep is the throwaway-but-inspect variant: a temp HOME that skips the cleanup trap and prints its path to stderr.
Named holes in the wall (eval harnesses)
env -i rebuilds the inner environment from scratch, so a fixture shim and its env contract need explicit pass-through — the Vertex passthrough pattern, generalised:
"$SCRIPT" -p --env "MY_FIXTURE=/path/world.json" --env "MY_LOG=$RUN_DIR/calls.log" \
--path-prepend /path/to/shim-bin -- "prompt"
--env KEY=VAL (repeatable) passes one variable through the wall. --path-prepend DIR (repeatable) puts a directory first on the inner PATH, so a shim binary shadows nothing the caller leaks — the inner PATH stays minimal otherwise. Print mode terminates claude's option parsing with -- before the prompt, so variadic flags (--allowed-tools, --tools) cannot swallow it. The boundary holds as ever: these punch context holes; the wall is not a security boundary, and an inner model can still read the host filesystem — one eval run demonstrably did (2026-08-05).
Vertex setups
If the caller's environment has CLAUDE_CODE_USE_VERTEX=1, ardoise auto-detects it and passes the Vertex config (project, region, model ids) and gcloud ADC through the isolation wall — so it works on, and bills to, a Vertex setup. Without this the env -i scrub strips the Vertex config and either hard-fails (Vertex-only boxes have no .credentials.json) or silently falls back to Anthropic-API billing (dual-cred boxes). No flag needed.
From Claude Code (OuterClaude calling InnerClaude)
"$SCRIPT" -p --max-turns 1 "Your prompt here"
The env -i scrub removes CLAUDECODE=1, so the inner Claude doesn't know it's nested. No launch resistance.
What the Ardoise Claude Sees
| Layer | Visible? |
|---|
| Global CLAUDE.md | No |
| Project CLAUDE.md | No |
| Custom skills (plugin cache) | No |
| Built-in skills (simplify, loop, claude-api) | Yes — compiled into Claude Code |
| Hooks | No |
| MCP servers | No |
| Plugins | No |
| Host filesystem | Yes — context isolation, not security sandboxing |
Key Discovery: The ~/.claude.json Symlink
Claude Code reads config from $HOME/.claude.json (a symlink in HOME root), not directly from $HOME/.claude/claude.json. Without this symlink in the temp HOME, Claude treats every launch as brand new and shows the onboarding wizard. The script creates this symlink automatically.
Composing with Other Skills
| Skill | How they compose |
|---|
| skill-forge | Eval baselines — run prompts without the skill for A/B comparison |
Anti-Patterns
| Anti-Pattern | Problem | Fix |
|---|
| Use Agent/Task tool for "naive" testing | Subagents inherit full parent context | Use this script via Bash tool |
Pass --system-prompt and assume isolation | CLAUDE.md still loads | Use ardoise.sh |
Use --allowed-tools "" for tool-free mode | Model burns turns trying tools | Pass --tools "" |
| Mount the real HOME | Context leaks | Let the script handle HOME |
| Fresh sandbox per step of a multi-step test | Loses marketplace/install state between calls | Use --home DIR to persist one sandbox |
Forget the ~/.claude.json symlink | Onboarding wizard every time | Script handles this automatically |
