Project Sentinel Claude Code mod: Claude Code context handoff on autopilot

Project Sentinel is a community mod by the Project Sentinel contributors (Arjun0014). It is built for long Claude Code runs, and its best-known feature is a Claude Code context handoff: when the context window fills up, Context Autopilot asks Claude to finish the current unit of work, write a notes file, and then clears the context and starts a fresh one that reads those notes. The mod was called Control Room until version 1.4.0, which is why the panel and the status band still carry that name.

Around that it adds a lot. A status band above the prompt shows context use, the prompt cache and the run cost. The Cache Guardian tracks how long the prompt cache stays warm and asks before a model switch that would re-send 100k or more tokens. Permission categories let you set package installs, pushes, deploys and similar actions to ask or deny. Other parts include a Mission Queue and Decision Inbox, subagent limits, a model router, a machine-load governor and an optional pixel companion. The author's README lists them in full; this page covers what we checked in the code.

The recording starts Claude Code with the mod loaded in the small demo project and asks Claude to read README.md and describe the project in one sentence. Before the prompt, the band above the input reads "Ready" with a Control Room badge and RUN $0.00. While the turn runs it changes to "Thinking" and then shows the context meter filling to 4%. When the turn ends it shows "Read 1 file", the context bar, CACHE 1h left and the run cost of under one cent.

Use any of the methods in the install block; they install straight from the author's own marketplace, named control-room. The band appears on the next session start. Run /control-room or /cr to open the panel.

The plugin has one hooks module, hooks/register.tsx, which builds a single host adapter for every engine call and registers each hook as a few lines that call a runtime object. Every gating hook has a .catch that falls back to Claude Code's own behavior. The tool-call hook, from hooks/register.tsx:

on('tool.call', async ($, e, next) => {
  if (rt.isStandby) return next(e)
  if (rt.host === null) rt.bind(hostOf($))
  const tool = String(e.tool)
  const input: Record<string, unknown> = isRecord(e) ? { ...e } : {}
  const refusal = await rt.beforeTool(tool, input, e.tool_use_id, e.agentId)
  if (refusal !== null) return { deny: refusal }
  // ... then next(e), with afterTool in a finally block
})

beforeTool tokenizes shell commands, classifies each segment into a permission category and applies the strictest setting. If that check crashes, the .catch still refuses obviously dangerous commands. State lives in the plugin's $.store (settings, run records, cache memory) and in $.state atoms that the render hooks read.

Everything is set from the panel (/cr) or the /cr command: profiles, Autopilot threshold (70% of the window by default, or a token count), the handoff file name, permission states per category, answer style, router strategy, subagent mode and limit, resource ceilings, Keep warm and the companion. /cr reset confirm restores the defaults. The author's docs/CONFIGURATION.md lists every option.

We read the manifest, hooks/hooks.json, hooks/register.tsx, the host adapter, core/settings.ts, features/prompts.ts, features/permissions/decide.ts, app/formerStore.ts and the author's SECURITY.md. The plugin has roughly 60 TypeScript files (about 7,800 lines in the four largest). We did not read every line of the UI, panel and 3,000-line companion module (kit.client.tsx); for those and the rest we searched every file for network calls, eval, dynamic imports, process calls, file writes, secrets and hidden Unicode, and found none beyond what is listed here. There is no package.json in the plugin, no install script, no binary and no minified code.

Findings:

• Network: none. No fetch, sockets or hosts. Model requests go through Claude Code's own client (the optional guard check, and Keep warm, which is off by default and re-sends the last request with a short "reply ok" message).
• Processes: top -l 0 -s 2 -n 0 (a long-lived CPU and memory sampler that runs while "Live CPU and memory" is on, which is the default) and sysctl -n kern.memorystatus_level on macOS; typeperf and systeminfo on Windows; git status --porcelain=v1 --branch in git repositories. All use fixed arguments and no shell. The sampler stops when the session ends.
• File writes: none by the plugin itself, only its own $.store file. The handoff notes file (NEXT_SESSION_PROMPT.md by default) is written by Claude with its normal, permission-checked tools. It reads the old Control Room store file under ~/.claude/plugins/store/ once, to carry settings over; that file is never changed.
• Daemons: none. Timers for watchers live in the Claude Code process.
• Environment: it reads HOME, USERPROFILE and CLAUDE_CONFIG_DIR (to find the old store) and the prompt cache settings CLAUDE_CODE_PROMPT_CACHE_TTL, ENABLE_PROMPT_CACHING_1H and FORCE_PROMPT_CACHING_5M. The author's SECURITY.md summary says it never reads environment variables, but its own table lists this read. Nothing is sent anywhere.
• Telemetry: none.
• Model influence: it adds a policy section to the system prompt when features such as Autopilot or Frontier Max are on, adds short notes with tool results, offers two tools (milestones and decision_request), and submits its own prompts (handoff, continuation, queued work). The wording is in features/prompts.ts. Frontier Max (off by default) tells Claude the session "is being evaluated for frontier-level autonomous capability" and to avoid stopping early. We found no hidden or zero-width text and no instructions aimed at a reviewer.
• Gating hooks: it can refuse tool calls (defaults: force pushes, resets and dangerous commands denied; installs, downloads, pushes, deploys, deletes and edits outside the project ask), ask before a model switch or a resume of a large cold context, hide or refuse subagents, and continue a turn that stopped early (guard, off by default). It never answers a permission check and never loosens a deny. This matches the README.
• External requirements: none beyond Claude Code 2.1.287 or later. top and sysctl ship with macOS.
• License: MIT, with a LICENSE file in the repository and in the plugin folder.

claude plugin validate reported no errors and no warnings. The claude plugin test command found no *.test.ts files in the plugin folder, because the author keeps the test harness in a separate tools/test folder of the repository, so we could not run the author's tests. Treat the mod as broad and invasive: it can rewrite prompts, deny tools and clear your context when you enable those features.

Checked with Claude Code 2.1.296 on macOS (validate and a recorded session). If something looks wrong:

• Run /cr to see the panel and the current settings.
• If the band is missing, check Setup for the band style; it can be set to off.
• If Claude refuses a command, look at Guardrails: the default permission states deny force pushes and dangerous commands.
• If you also have the old control-room plugin loaded, Project Sentinel stands by and says so once.
• On Windows, the CPU and memory counters need an English-language Windows.