Claude Code
The first host. Bundled hooks and MCP server, the sandbox and permission model, memory routing, and running homes on separate accounts.
Claude Code is where Kevin was built and where every feature is exercised first. The plugin manifest registers the skills, the four hooks, and the kevin MCP server, so a session launched from a home gets all of it with no per-home wiring.
| Launch | claude from the home |
| Skills | /agent-kevin:<skill> |
| Manual | AGENTS.md through the @-imports in .claude/CLAUDE.md |
| Hooks and MCP server | Bundled with the plugin |
| Settings | .claude/settings.json (permissions) and .claude/settings.local.json (env, gitignored) |
| Reload after a plugin update | /reload-plugins; new hooks need a full relaunch |
Hooks
The four hooks ship in the plugin's hooks/claude.json. Claude Code runs a plugin's hooks only for sessions started where the plugin is enabled, so a session can only ever be captured by the agent whose home it launched in. See Hooks for what each one does.
Do not add capture hooks to ~/.claude/settings.json
Earlier versions recommended machine-wide hooks routed by a KEVIN_HOME variable. That hands every session on the box to one brain. Plugin hooks are the only supported path.
Permissions and the sandbox
Init pre-grants the always-on core tools in settings.json. Pack tools land there only when you activate the pack through configure-skills, so the file stays an accurate audit trail. A few entries sit in permissions.ask (git push, gh pr create, curl_run, seed_import): an ask rule is evaluated before Claude Code's auto-mode classifier and cannot be approved past, which makes it the one durable form of "nothing leaves this machine without a human".
The Bash tool runs under a sandbox that denies reads of .kevin/secrets/ and every .env. The MCP server runs outside that sandbox, which is how the GitHub tools, worktree setup, and the upgrade scripts do the writes the seatbelt blocks. See MCP tools.
Memory routing
Claude Code ships an auto-memory directory under ~/.claude/projects/. Kevin does not use it. The .claude/CLAUDE.md bridge overrides that instruction so every correction, preference, project fact, and reference routes into the knowledge/ tree, which is what stays portable across hosts and what every other tool in the home reads.
Multiple accounts
/login is a single slot per OS user, so on its own it cannot keep two homes on two subscriptions. CLAUDE_CODE_OAUTH_TOKEN can: it sits above the login slot in credential precedence, and each session resolves its own settings.local.json env block at launch.
# /login as account A, then:
claude setup-token # OAuth flow, prints a token for account A
# put it in home A's settings.local.json; repeat for account B and home B{ "env": { "CLAUDE_CODE_OAUTH_TOKEN": "sk-ant-oat01-..." } }This is the one credential that lives in settings.local.json rather than the secrets store, because Claude Code consumes it at launch, before Kevin's tools exist. The file is gitignored.
Gotchas: switch /login between mints or you get two tokens for one account; the env block is read at launch, so restart after adding it; an ANTHROPIC_API_KEY in your shell rc silently outranks the token; verify with independent /usage meters, not the shell.
Verifying subscription billing
The host does the thinking, so nothing bills the API. To see it: open Anthropic Console → Usage and note the API cost, run the knowledge-compile skill, refresh. API cost should not change. Subscription usage should increment. If it does change, open an issue.