Proposal · v2 draft · for team review

The DE Quarantine

Cowork keeps every DE tool the team relies on — untouched by construction. Claude Code sessions in engineering repos load none of it, enforced by where things live, not by anyone remembering.

Draft v2 for red-pen · Cowork untouched by design · no changes land until ratified

Jump by type: what changed in v2 · where we are · personal skills sidebar · open questions · risks · rollback

01

What changed in v2 — the Cowork finding

Robert’s constraint: the team relies on DE tools in Cowork — any quarantine must leave Cowork exactly as it is. The verified answer: Cowork and Claude Code don’t share configuration at all. Cowork loads the plugins and connectors enabled for each person’s claude.ai account, synced at session start, and never reads the machine’s Claude Code config. So the “natural switch” Robert intuited already exists structurally: Cowork is untouched by construction, the quarantine is a Claude-Code-only job — and most of it is already done.

↘ go deeper — the source of that claim
Official Cowork docs (claude.com/docs/cowork): Cowork “loads the ones enabled for your claude.ai account, synced at session start, and doesn’t read the Claude Code CLI’s ~/.claude directory on your machine.” Verified via the docs agent 2026-08-12. It’s documentation, not yet observation — which is why the proving walk re-confirms it on a real teammate account before rollout.
02

The problem, and the principle

DE’s business tools — the brain (DE’s knowledge assistant) and the hub (the bundle carrying DE’s skills) — were installed at the machine level in Robert’s Claude Code setup, so they loaded into every repo session, including pure engineering repos, where they distract the session and blur its focus. As teammates start working in engineering repos, the same failure would replicate on their machines.

Quarantine by placement, not by blocklist — per surface. Cowork’s tool surface belongs to the claude.ai account (untouched by this plan). Claude Code’s tool surface belongs to the machine + the repo — and there, the machine carries nothing business-specific; repos opt in only if they genuinely need DE tools. Engineering repos are clean by default, and carry one defensive line so they stay clean even on a machine someone later misconfigures.
03

Where we are today (verified 2026-08-12)

By design
Cowork — untouched, whole team
Cowork reads each person’s claude.ai account, not their machine. Nothing in this plan can reach it. Re-confirmed on a real teammate account during the proving walk.
Done today
Brain’s global hookup — removed
The machine-wide registration that pushed the brain into every Claude Code session is gone (Robert ran the removal). Only two neutral engineering tools remain global.
Done already
Hub plugin — off by default
Installed but switched off at the machine level, so its 60+ business skills no longer load anywhere in Claude Code by default. Robert’s machine is effectively quarantined now.
Verified
One switch carries the whole surface
The hub plugin bundles its own connections — brain, spotlight command center, edit-request box, design and image tools — and ships from a GitHub repo DE owns. Any repo that opts in gets everything with one line.
04

The moves — smaller than v1

Robert’s machine is done. What remains is defensive hardening for teammates, plus proof.

  1. The machine stays empty. Nothing DE at the Claude Code machine level: no global brain hookup, hub plugin off. A teammate’s machine needs nothing at all — their DE-in-Cowork comes from their claude.ai account, not their machine.
    ↘ go deeper — what “empty” means concretely
    On Robert’s machine the global connection list (~/.claude.json) now carries only two neutral engineering tools (solo, plato); the personal settings file has the hub plugin explicitly off ("de-hub@de-skills": false). No DE endpoint is registered machine-wide.
  2. Engineering repos check in a defensive “off.” The engineering repos — a small, named list (open question 1) — each commit a one-line setting that disables the hub plugin for that repo, regardless of machine state. Even if a teammate someday enables the hub globally in their Claude Code, the engineering repos stay clean by their own word.
    ↘ go deeper — the exact line and why it wins
    In the repo’s committed .claude/settings.json: { "enabledPlugins": { "de-hub@de-skills": false } }. Repo-level settings override user-level ones (documented precedence: managed → command line → local → project → user). One caveat rides in the risks: a known upstream bug around plugin-enablement overrides in a different scope — the proving walk’s override check is the real gate.
  3. DE repos may opt in — if any need it. Any repo where DE tools genuinely belong in Claude Code sessions commits the mirror line (“on”). If the team’s DE work happens entirely in Cowork, this list is empty and the stage is a no-op — that’s open question 1.
  4. The proving walk — the load-bearing stop. Four checks before rollout: Cowork on a real teammate account shows every DE tool working, before and after the repo changes. A fresh Claude Code session in an engineering repo on Robert’s machine shows zero DE surface. The override check: with the hub deliberately enabled at user level, an engineering repo with the defensive off still shows zero. And the connector-leak check: whatever gives Cowork the brain does not also appear inside a Claude Code repo session on the same machine.
    ↘ go deeper — why each check exists
    The Cowork check turns a documentation claim into an observation. The override check proves repo-off beats user-on on the exact version the team runs (and stands guard against the known upstream settings bug). The connector-leak check exists because the docs are silent on whether claude.ai connectors flow into Claude Code sessions — we don’t assume either way. And every check is run cold — fresh sessions, because running sessions keep whatever they loaded at start.
  5. Rollout — two tiny PRs and a note. The defensive offs land via normal pull requests to the engineering repos, plus a comms note: “nothing changes in Cowork; restart any open Claude Code sessions.” No teammate onboarding needed unless a repo opts in — then a one-time plugin install from DE’s GitHub catalog, documented in that repo’s README.
05

Sidebar: Robert’s loose personal skills

About fifty skills live loose on Robert’s machine and load in every Claude Code repo — the daily briefing, deal board, meeting prep, wrap-up rituals, plus general engineering aids. Two facts keep them out of the team plan: they are machine-local (they never distribute to teammates), and they are personal rituals or general engineering aids, not DE business tools — the confusion in engineering sessions came from the brain and the hub, which the moves above quarantine.

Recommendation: leave them global on Robert’s machine for now. Optional later tidy: any skill that should become a team skill graduates into the hub plugin.

06

Open questions — the red-pen targets

1
Does any repo need DE tools inside Claude Code at all?
If the team’s DE work happens entirely in Cowork, the opt-in list is empty and this plan reduces to two defensive PRs. And which engineering repos get the defensive off — the site factory, the website-edits compiler, others?
2
How does the team’s Cowork get the brain today?
A claude.ai connector (organization-level or personal) or a plugin enabled on their accounts? Determines exactly what the Cowork check and the connector-leak check look at during the proving walk.
3
Personal skills.
Confirm the “leave them global on Robert’s machine” recommendation, or ask for the tidy now.
07

Risks — the honest list

Docs vs reality
The Cowork / Claude Code separation is documented, not yet observed by us. The proving walk’s Cowork check on a real teammate account is the gate — nothing rolls out on the strength of a doc page alone.
Undocumented connector flow
Whether claude.ai connectors also appear inside Claude Code sessions is not covered by the docs either way. The connector-leak check exists precisely for this — it’s the sharpest remaining way DE tools could still reach an engineering repo.
A known settings bug
An open upstream issue (claude-code #25086) reports plugin-enablement overrides being silently ignored in one settings scope. Our defensive off uses a different scope, but we trust the walk’s override check, not the docs.
Stale sessions
Sessions already running keep old config until restarted. Rollout comms must say so, or the change looks broken when it isn’t.
08

Rollback

Every move in this plan is a settings line. Revert = flip the line back. Nothing is deleted anywhere — not skills, not the plugin, not the brain’s server — and nothing in anyone’s claude.ai account is touched at any point.