When the Sandbox Leaks: Context Contamination Across LLM Workspaces

Source: Dev.to

Introduction

I had two workspaces. One was a sandbox — messy, exploratory, version‑controlled on GitHub. The other was a curated portfolio — polished, employer‑facing, local‑only. The boundary between them was architecturally clear: research stays in the sandbox, finished artifacts get promoted one‑way to the portfolio. Simple.

Except the boundary kept failing.

I found three copies of my Obsidian vault in different locations on my machine — Systemic_Intelligence_Vault, Systemic_Intelligence_Vault_Antigravity, and Systemic_Intelligence_Vault_Claude. Each was a variant with slightly different content. Scripts would target the wrong root directory. Absolute paths from the portfolio showed up hard‑coded inside sandbox files, coupling two systems that were supposed to be independent. And the part that should have bothered me most — I’d already designed solutions for all of this months earlier: beacon files, verification scripts, promotion gates. They were documented in my Program Architecture. They just weren’t enforced.

That’s when I realized: documentation isn’t a boundary. Enforcement is.

I’m John. I’ve been building a knowledge‑management system across multiple LLM environments and workspaces for the past six months — a sandbox for research, a portfolio for curated work, and models operating in both. This is Part 2 of Building at the Edges of LLM Tooling, a series about what breaks in sustained LLM workflows. Start from the beginning here.

Why It Breaks

Contamination between workspaces isn’t dramatic. It’s entropic. You copy a folder for backup. You reference a path in a script. You create a variant for testing. Each action is small and reasonable. But without enforcement, they accumulate into what I started calling spaghetti — tangled, unclear boundaries where messy research bleeds into curated space and curated assumptions leak back into exploratory work.

LLM‑assisted workflows multiply this entropy. Every IDE agent, every model session, every tool creates its own assumptions about where things live and what the rules are. A model operating in one copy of your repository doesn’t know another copy exists. It doesn’t know its configuration file differs from the one in the canonical version. It just follows whatever instructions it finds.

This creates three contamination vectors I kept hitting.

1. Path contamination

• Multiple copies of a project in different locations, no single canonical root.
• Scripts break.
• Models reference wrong directories.

When my MP assistant surfaced that I’d previously hit “wrong root, wrong name, quoted ~” failures — and that I’d already designed beacon files to prevent them — that was the signal. I was solving the same problem a second time because the first solution was a document, not a gate.

2. Behavioral contamination

• Invisible, which makes it worse.

• A diff between the main vault and the Antigravity variant showed nearly identical content, but the .cursorrules files differed:

  • Main vault: “You are working inside the Systemic Intelligence Vault — a living knowledge system using Expansive Closure Protocol methodology.”
  • Antigravity variant: “You are working inside a local Obsidian vault.”

  Same content, same prompts, completely different AI behavior — different assumptions about the project, methodology, and file treatment. No error message, just quietly wrong outputs that I couldn’t explain until I diffed the configuration files.

3. Promotion contamination

• The one‑way flow from sandbox to portfolio is supposed to be a clean gate.
• Architecture doc was explicit: “No cross‑contamination of messy research into MP; promotion remains one‑way.”
• Without pre‑flight checks, drafts leak into the curated space.
• Without provenance tracking, you lose the lineage between source and promoted artifact.
• Without lane enforcement, raw chat transcripts and agent logs can accidentally get promoted alongside finished work.

What I Tried

The first instinct was procedural — checklists, hand‑off protocols, naming conventions.

• Documented which folders were forbidden from promotion.
• Wrote architecture docs explaining the one‑way flow.
• Created naming standards: YYYYMMDD_Title_v#.#.md in the sandbox, similar conventions in the portfolio.
• Detailed guardrails across five categories: conceptual, procedural, semantic, structural, behavioral.

It didn’t hold. Manual discipline degrades under load. You skip the checklist when you’re moving fast. You forget which copy is canonical after a week away from the project.

So I moved to technical enforcement. The pattern that emerged had three layers.

1. Beacon files for canonical roots

A zero‑byte .MASTER_PORTFOLIO_ROOT file dropped at the true root of the portfolio. Every script checks for it before operating. If the beacon is missing, the script fails immediately rather than silently working on the wrong directory.

“Pick one canonical root and treat everything else as a copy.” – MP assistant

Implementation is a trivial bash script:

#!/usr/bin/env bash
# abort if the beacon file is not present in the current directory tree
if ! find . -type f -name ".MASTER_PORTFOLIO_ROOT" -print -quit | grep -q .; then
  echo "Error: .MASTER_PORTFOLIO_ROOT not found – aborting."
  exit 1
fi
# …rest of script…

It sounds trivially simple, and it is. That’s why it works. You can’t forget it because it’s a hard gate, not a soft convention.

2. Pre‑flight checks before cross‑boundary operations

Before anything moves from sandbox to portfolio, a script verifies:

1. Is the source file actually in the sandbox repo?
2. Is it from a permitted lane?
3. Does it contain hard‑coded portfolio paths that would create coupling?
4. Is the metadata marked as ready for promotion?

Any failure blocks the operation.

3. Pointer‑only provenance

Instead of copying source context into the portfolio, promoted artifacts carry a provenance record with only metadata:

provenance:
  source_system: sandbox
  source_reference: "Systemic_Intelligence_Vault/20240312_DeepDive_v1.2.md"
  date: 2024-03-12
  promoted_items:
    - "DeepDive_v1.2.md"
  excluded_items:
    - "raw_chat_log.txt"
  rationale: "Final report for client presentation"
  hash: "sha256:3a7f5e..."

No content bleed. The portfolio stays clean while retaining a verifiable lineage back to the original research.

Takeaways

Documentation tells you what should happen. Enforcement makes sure it does happen.

The traceability chain remains intact.

For the behavioral contamination problem, the fix required a mindset shift: treat configuration files as part of the system, not as local preference. Version‑control *.cursorrules* and *.claude/settings.json*. Mark one copy as canonical and every variant as explicitly labeled. When the AI behaves differently than expected, the first diagnostic is “which copy am I in?” — and the beacon system makes that immediately answerable.

What It Revealed

Boundaries in LLM workflows exist at two levels, and most practitioners only build the first.

1. Conceptual level – This space is for exploration, that space is for finished work, and promotion flows one direction. Most people who think about workspace hygiene at all stop here. They document the architecture and trust themselves to follow it.

2. Enforcement level – The beacon that makes scripts fail if they’re in the wrong root, the pre‑flight check that blocks forbidden lanes, the version‑controlled configuration files that prevent invisible behavioral drift. This is where the boundary actually holds.

The gap between levels one and two is where spaghetti grows. The tell is recurring failures. When my own assistant surfaced that I’d already designed beacons and verification scripts months earlier — to solve the exact same failures I was hitting again — that was the signal. If you’re hitting the same contamination pattern twice, you didn’t fail at design. You failed at enforcement.

Another insight concerns invisible contamination.

• Content drift is noisy — you can diff files, see what changed, and merge the differences.
• Configuration drift is silent. Different *.cursorrules* across vault copies means different AI behavior with no error message, no visible discrepancy in the content, just outputs that feel subtly wrong. This is the hardest contamination to catch because there’s no signal until you think to look.

The Reusable Rule

If you maintain separate workspaces for exploratory and curated work — and if LLM agents operate in those spaces — contamination is the default without enforcement infrastructure.

1. Start with the diagnostic.

   • When you catch yourself re‑discovering where files live, that’s path contamination — drop a beacon file and make your scripts check for it.
   • When the AI produces unexpectedly different output for the same prompt, check which workspace copy you’re in — configuration drift is likely.
   • When you’re promoting work from sandbox to portfolio, ask whether the promotion path has a pre‑flight check or whether you’re relying on your own attention. Your attention will fail.

2. The anti‑spaghetti principle:

   Every boundary between workspaces needs a corresponding enforcement mechanism.

   • Conceptual boundaries document intent.
   • Enforcement mechanisms preserve that intent.

When the same failure recurs, the missing piece is almost never the design — it’s the gate that makes the design non‑optional.