Claude Stack Teardown

Each row is one real configuration point with the exact path it lives at. The status column is the part that matters for comparing setups:

Set configured and in use   Empty the file or directory doesn't exist   Needs auth installed but not authorized   Idle present but disabled or retired

Two surfaces are only partly inspectable. Claude Code config lives in files on disk, so all of it is verifiable. Claude.ai settings, Projects, Styles, and Cowork memory live server-side — those are marked and can only be confirmed in the web UI.

Instruction files

Settings, permissions and hooks

~/.claude/settings.json is the only user-scope settings file — there is no settings.local.json at that level.

{
  "enabledPlugins": {
    "obsidian@obsidian-skills": true,
    "blotato@blotato-skills": true
  },
  "extraKnownMarketplaces": { "obsidian-skills": …, "blotato-skills": … },
  "tui": "fullscreen",
  "theme": "dark",
  "skipWorkflowUsageWarning": true,
  "inputNeededNotifEnabled": true,
  "agentPushNotifEnabled": true
}

Plugins and marketplaces

MCP servers

Exactly one MCP server is configured locally, in ~/.claude.json. There are no .mcp.json files anywhere in the project tree — everything else visible in a session comes from claude.ai connectors, not local config.

Skills, commands and subagents

Scheduled tasks

Seven task folders in ~/.claude/scheduled-tasks/, each defined by a SKILL.md. Three are dead weight.

Twelve memory files plus a MEMORY.md index, one fact per file with typed frontmatter. Covered: role, six active projects, an Obsidian vault, a content pipeline, a hardware warning about a failing drive, and one catalog-hygiene rule.

Connectors

Roughly twenty connectors are installed but dead. They cost nothing but they clutter every tool listing and make the setup look richer than it is.

Skills actually used

Fourteen skills show real usage: xlsx, pdf, pptx, schedule (×2 variants), deep-research, claude-api, fewer-permission-prompts, artifact-design, artifact-capabilities, marketing:campaign-plan, cloudflare-email-service, wrangler, obsidian:obsidian-markdown.

Plugin bundles loaded inline: anthropic-skills, cowork-plugin-management, slack-by-salesforce, marketing, sales, obsidian, blotato.

1. An API key sits in plaintext. The one local MCP server stores its credential as a literal string in ~/.claude.json. That file gets backed up, synced and screen-shared. Rotate the key and move it behind an environment variable reference.
2. 3,307 permission rules in one project. Append-only sludge — individual image-conversion commands and specific URLs, each captured as its own literal rule. They do almost nothing, because the next command won't match. The /fewer-permission-prompts skill collapses these into patterns.
3. No global CLAUDE.md, no hooks, no global agents or commands. The harness setup here is genuinely strong — three specialized subagents with deliberately asymmetric tool grants and an evaluator that owns acceptance — but it only applies inside one folder. Nothing carries across projects.
4. Memory holds facts, not preferences. One feedback-type memory against eleven project-type ones. The things that make an assistant feel dialed in — how you want work reviewed, what to never do without asking, preferred output shape — aren't written down anywhere.
5. Twenty unauthorized connectors. Either finish the OAuth for the ones you'll use or remove the plugins, so the tool surface reflects reality.

The audit above was produced by a read-only shell script. It walks the same paths, prints the same sections, and replaces any header, token, key or password value with [REDACTED] before printing. It writes nothing and modifies nothing.

bash claude-setup-inventory.sh                 # audits the current directory
bash claude-setup-inventory.sh ~/code/myapp   # or a specific project

It reports: every CLAUDE.md with its headings · all four settings files with permission counts · hooks · installed plugins and marketplaces · MCP servers at user and project scope · connectors ever linked · skill and plugin usage · global and project skills, commands and subagents · scheduled tasks · every launch.json dev server.

Run it on both machines and diff the output — that comparison is the actual point, and it's far faster than reading two of these documents side by side.