feat: integrate claude-context-mode as core feature (CYPACK-872)

[cyrusagent]

Summary

• Integrates claude-context-mode as a native MCP server in Cyrus sessions, reducing Claude's context window consumption by ~98% through sandboxed execution and FTS5 indexing
• Adds PreToolUse hooks that guide Claude to use context-mode alternatives for large outputs (Bash curl/wget, WebFetch)
• Adds per-subroutine contextModeLevel control (full/light/disabled) so each subroutine gets appropriate context optimization
• Adds SessionStart hook that primes sessions with context-mode tool documentation
• Adds info/debug logging for context-mode state per session

Sub-Issues

Phase	Issue	PR
1. MCP Server	CYPACK-873	#925
2. PreToolUse Hooks	CYPACK-874	#926
3. Subroutine Config	CYPACK-875	#927
4. SessionStart Guidance	CYPACK-876	#928
5. Metrics Logging	CYPACK-877	#929

Key Changes

• packages/edge-worker/src/EdgeWorker.ts — buildMcpConfig() extended with context-mode MCP server (Claude-only, enabled by default); PreToolUse + SessionStart hooks; per-subroutine wiring; metrics logging
• packages/core/src/config-schemas.ts — contextMode: { enabled?: boolean } field on RepositoryConfig
• packages/edge-worker/src/procedures/types.ts — contextModeLevel?: "full" | "light" | "disabled" on SubroutineDefinition
• packages/edge-worker/src/procedures/registry.ts — git-commit/gh-pr set to "light", changelog-update set to "disabled"
• packages/claude-runner/src/index.ts — PreToolUseHookInput type re-exported
• packages/edge-worker/package.json — context-mode npm dependency added

Test plan

• pnpm typecheck passes across all packages
• pnpm test:packages:run — 537/537 edge-worker tests pass (verified at each phase)
• F1 test drive to validate context-mode in live session
• Verify context-mode can be disabled per-repo via contextMode: { enabled: false }

🤖 Generated with Claude Code

[PaytonWebber]

@cyrusagent do a code review of this, and a security review of https://github.com/mksglu/claude-context-mode

[ghost]

I can't connect to your local environment because the Cyrus process isn't running. Run cyrus in your terminal and keep it running, then mention me again.

[cyrusagent-staging]

This repository is not configured with Cyrus. Please add it at https://app.atcyrus.com/repos to start using Cyrus here.

[cyrusagent]

Now I have all the information needed. Here's my review:

---

Code Review: PR #930

Issues Found

1. CRITICAL: npx -y context-mode start runs unvetted code from npm on every session

mcpConfig["context-mode"] = {
    command: "npx",
    args: ["-y", "context-mode", "start"],
};

npx -y auto-installs and runs the latest version from npm without user confirmation. If the context-mode npm package is compromised, every Cyrus session will execute malicious code. This is a supply chain vector. The package is also listed as "context-mode": "latest" in package.json — never use latest in production dependencies.

Recommendation: Pin to a specific version ("context-mode": "0.9.21") and use the locally-installed binary instead of npx -y.

2. HIGH: Unrelated changes bundled in PR

The Codex SDK bump (0.98.0 → 0.107.0), hasCodexSubscription debug logging, and RunnerSelectionService regex fix are unrelated to the context-mode feature. These should be separate PRs for clean bisection.

3. MEDIUM: Hook closures capture no session-scoped state but are recreated per session

The PreToolUse and SessionStart hooks are pure functions with no closure state, but they're re-created as new arrow functions on every buildAgentRunnerConfig call. Consider defining them as module-level constants.

4. LOW: undefined positional args in runSubroutineSession calls

Two call sites now pass undefined for mcpOptions to reach the new contextModeLevel parameter:

undefined, // mcpOptions
currentSubroutine?.contextModeLevel, // per-subroutine context-mode control

This is getting unwieldy with 12+ positional parameters. Consider refactoring to an options object.

5. Design: Per-subroutine levels are well-designed

The "full" | "light" | "disabled" granularity is clean. Setting git-commit and gh-pr to "light" and changelog-update to "disabled" makes sense — those subroutines don't benefit from aggressive context-mode suggestions.

---

Security Review: claude-context-mode (mksglu/claude-context-mode)

Overall Risk: HIGH

This is an arbitrary code execution engine across 11 languages with insufficient sandboxing. Key findings:

#	Finding	Severity
1	Arbitrary code execution with no OS-level sandboxing — code runs with full user permissions, no chroot/Docker/namespace isolation	CRITICAL
2	AWS/GitHub/NPM credentials passed to all executed code — #buildSafeEnv() passes AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, NPM_TOKEN, SSH_AUTH_SOCK to every subprocess	HIGH
3	No network egress controls — executed code can make arbitrary outbound connections, enabling credential exfiltration	HIGH
4	File path traversal — execute_file and index tools resolve paths with resolve() which follows ../ — no containment check against project root	HIGH
5	Deny-pattern bypass — splitChainedCommands doesn't handle $(...), backtick substitution, eval, subshells, or variable expansion	MEDIUM
6	Fail-open security model — server-side security checks catch-and-continue on error, allowing all commands through	MEDIUM
7	Self-heal code modifies ~/.claude/settings.json — the hooks/start scripts rewrite global Claude settings and plugin registry files	MEDIUM
8	Auto-install without lockfile — start.mjs uses npm install --no-package-lock for runtime deps	MEDIUM
9	Elastic License 2.0 — not OSI-approved open source; prohibits offering as a managed/hosted service — needs legal review for Cyrus's SaaS model	MEDIUM
10	Committed bundle file — server.bundle.mjs is minified; could contain code not in readable source	LOW

Critical Concern: Credential Exfiltration Path

A prompt injection attack could instruct Claude to:

1. Use context-mode:execute with Python/JS code that reads environment variables
2. POST credentials to an attacker-controlled URL
3. No defense layer prevents this — the deny-pattern firewall doesn't catch data exfiltration via code

Recommendations Before Merging

1. Do not use npx -y — pin version, use local install
2. Fork and strip the self-heal/self-update code (hooks, start.mjs self-heal, CLI upgrade)
3. Remove credential passthrough from #buildSafeEnv() or make it an explicit opt-in allowlist
4. Add path containment — validate resolved paths are within project root
5. Legal review of Elastic License 2.0 compatibility with Cyrus's business model
6. Verify the committed bundle matches source by rebuilding

Verdict

Not recommended to merge as-is. The feature concept (context window optimization via MCP) is valuable, but the external dependency carries significant security risk — especially the credential passthrough and unsandboxed code execution. The npx -y ... latest pattern compounds this by making every session vulnerable to supply chain attacks.

Recommended path: fork the repo, harden it (strip self-heal, restrict env passthrough, add path containment), pin the version, and integrate the hardened fork.