Ardoise

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):

Additional env vars suppress noise:

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"
# Fallback if CLAUDE_PLUGIN_ROOT isn't set in the calling context:
[ -x "$SCRIPT" ] || SCRIPT=$(find ~/.claude/plugins/cache -path "*/trousse/*/scripts/ardoise.sh" 2>/dev/null | sort -rV | head -1)

The fallback uses sort -rV | head -1 to prefer the highest-versioned cached copy when multiple are present. The -V (version sort) matters: plain sort -r is lexicographic and resolves 1.8.7 above 1.66.0, handing you a script months behind the skill instructions invoking it.

Interactive mode (default)

"$SCRIPT"                    # TUI in /tmp
"$SCRIPT" ~/some/project     # TUI in a specific directory

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
"$SCRIPT" -p --cwd ~/some/project "What does the README promise?"

Print mode runs in /tmp by default; --cwd DIR runs the subject in a chosen directory instead (the seeder pre-trusts it, so no trust dialog blocks the run). Use it whenever the probe must see a real repo, or when /tmp's shared clutter could contaminate the subject's view.

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         # seeded once, reused thereafter
"$SCRIPT" --home ~/ardoise-sbx -p "verify it loaded"   # same HOME, accumulated state intact

--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)

# In a Bash tool call:
"$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

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

Anti-Patterns