mksglu/context-mode

Summary

Context Mode is an MCP server that acts as a sandboxed execution and indexing layer between AI coding assistants (Claude Code, Gemini CLI, VS Code Copilot, etc.) and their context windows. It intercepts tool calls (Bash, WebFetch, Read), runs them in isolated subprocesses, indexes the raw output into a SQLite FTS5 database, and returns only BM25-ranked snippets instead of dumping full output into the context window. It also maintains session continuity across LLM compaction events by tracking file edits, git operations, tasks, and user decisions in a persistent SQLite store.

Great for

people interested in building protocol-level infrastructure for AI coding assistants — specifically context management, sandboxed code execution, and session continuity across LLM conversation compaction

Easy wins

• +Add a new adapter config for an unsupported AI client — the pattern is well-established in src/adapters/ with corresponding tests in tests/adapters/, and configs/ shows the file layout expected
• +Improve the 'help wanted' issues (2 labeled) — the issue templates are structured and the test fixtures in tests/fixtures/ make it easy to write regression tests
• +Add test coverage for hooks/userpromptsubmit.mjs and hooks/routing-block.mjs — these appear in the file tree but have no corresponding test files in tests/hooks/
• +Extend language support in the executor — src/executor.ts and src/runtime.ts have a clear pattern per language, and tests/executor.test.ts uses describe.runIf() guards that make it safe to add new runtimes

Red flags

• !License is 'Elastic-2.0' (ELv2) — this is NOT open source by OSI definition; contributors cannot use this in competing SaaS products, which some developers may not realize from the README's framing
• !commit_count: 1 and contributor_count: 1 in the metadata despite showing 20 contributors and 301 forks — the stats.json badge system is self-hosted on the repo, making user/npm counts unverifiable
• !The JS network instrumentation in ctx_execute (the __cm_net closure) shadows CJS require at runtime with no tests for edge cases — ES module code passed to ctx_execute would bypass the http/https interception entirely since require doesn't exist in ESM scope, silently giving wrong network byte counts
• !hooks/session-db.bundle.mjs, hooks/session-extract.bundle.mjs, hooks/session-snapshot.bundle.mjs are pre-built bundles committed to the repo — contributors editing src/session/ files must remember to rebuild these or hook behavior won't match source

Code quality

The source samples show solid TypeScript with strict mode, explicit types, and deliberate error handling patterns (fail-open security checks with try/catch comments explaining the choice). The search cascade in store.ts (porter → trigram → fuzzy with matchLayer tracking) is well-designed and thoroughly tested with 7 clearly-separated test sections. The FTS5 highlight marker parsing in server.ts (positionsFromHighlight using STX/ETX) is a non-obvious but correct approach. One concern: the JS instrumentation wrapper injected into user code in ctx_execute (the ~50-line `__cm_net` network tracking closure) is brittle — it patches globalThis.fetch and shadows require at runtime, which will break for ES modules or Bun's native fetch, and there's no test coverage for this instrumentation path specifically.

What makes it unique

This is genuinely solving a real and non-obvious problem — LLM context pollution from verbose tool outputs — at the protocol layer rather than with prompt engineering. The three-layer FTS5 search cascade (porter stemming → trigram substring → fuzzy correction) for intent-based retrieval is more sophisticated than most projects in this space. The multi-client adapter architecture (9 clients with per-client hook formatters) is rare. The closest comparison would be something like mem0 or Zep, but those focus on long-term memory rather than within-session context compression.