If you’re running multiple projects in AI-assisted workspaces, you hit a structural problem fast: shared projects (with clients or partners) and private projects (just yours) need different access boundaries, but you want one set of agents reading across them.

The solution is VS Code multi-root workspaces with deliberate folder layout.

The Setup

A single .code-workspace file at the top level:

{
  "folders": [
    { "name": "Alcanah AI",    "path": "Alcanah AI"    },
    { "name": "Nice Green",    "path": "../Nice Green" },
    { "name": "Lunix",         "path": "../Lunix Leadership" },
    { "name": "Shikohin Inc",  "path": "../Shikohin Inc" },
    { "name": "Saucy Bot",     "path": "../Saucy Bot"  }
  ]
}

Each folder is its own git repo. Each has its own CLAUDE.md, its own session logging, its own goals. They live side-by-side as siblings on disk.

Two folder visibility rules:

  • Operator-private repos (Alcanah AI, Shikohin Inc) live in ~/Documents/... alongside the others. Their CLAUDE.md declares operator-only access. Nothing in these repos ships to any other location.
  • Shared repos (Nice Green, Lunix, Saucy Bot) have their own git remotes shared with partners. Anything checked into these repos is visible to collaborators.

The multi-root workspace shows all of them in one VS Code window, but each repo is independent.

What Makes It Work

Access boundaries defined in the master CLAUDE.md. The root instance (Alcanah AI) has rules like “this folder is private to the operator” and “client workspaces are shared repos. Do not store operator-specific config there.” The AI loads these rules at session start and respects them throughout.

Cross-repo agents live in the operator-private repo. Session-logger, status-reporter, calendar-audit, etc., run from .claude/agents/ in Alcanah AI but reach into sibling folders via ../ paths. They can READ across boundaries (to generate cross-portfolio reports) but they’re configured to WRITE only into the correct repo per project.

Per-project session logs. Each repo’s logs/ lives in its own repo. Temp logs are namespaced by project + username + date. When a cross-project agent consolidates, it writes to the right repo’s log, never crosses streams.

Privacy by architecture, not by attention. The boundary is enforced before the prompt arrives. The AI can’t accidentally include operator personal goals in a client-facing report because the rules-loading happens at the workspace level, not inside any specific conversation.

What Breaks Without This

Three failure modes I hit before getting the layout right:

  1. Operator details leaking into client deliverables. Without folder boundaries, the AI would reference personal projects when generating client reports. Once you have folders and rules, this stops.
  2. Client repos accumulating operator-only files. Configs that should stay private (auth inventories, credential pointers, internal goals) would land in shared client repos because the AI didn’t know better. Folder boundaries plus an audit checklist before pushing fixed this.
  3. Cross-repo agents writing to the wrong repo. Session-logger would write Alcanah work into a client repo’s session log because the path resolution was relative to the active editor. Forcing explicit project routing in agent definitions fixed this.

The Generalization

If you’re managing multiple AI-assisted projects with mixed privacy requirements, VS Code multi-root workspaces aren’t optional. They’re the only sane way to have one editor view of all your work while keeping the boundaries that prevent data from drifting where it shouldn’t.

The .code-workspace file is the manifest. The folder structure is the contract. The CLAUDE.md files are the enforcement. All three pieces together, or you’re going to leak something.