Context Mode Claude skills

How the sandbox and knowledge base work

When the agent calls ctx_execute, the code runs in a subprocess, and only what it prints to stdout comes back into the conversation. The skill files list JavaScript, TypeScript, Python and shell among the supported languages. ctx_execute_file loads one file into a FILE_CONTENT variable inside the sandbox. The agent can then count, filter or summarize that file without the raw text entering the context window. There is no separate ctx_read tool.

Output worth keeping goes into the local SQLite FTS5 store. The README describes two tokenizers. Porter stemming means a search for "caching" also matches "cached" and "caches". A trigram tokenizer handles partial strings, so "useEff" finds "useEffect". ctx_search does not cut results off at the first N characters. It finds where the query terms appear and returns those passages.

If you resume with --continue, indexed documents survive a restart and the agent does not have to fetch the same page again. If you start a session without --continue, the previous session's data is deleted.

A typical workflow with the routing rules

The routing skill gives the agent a fixed order of operations:

1. Gather with ctx_batch_execute(commands, queries). It runs several repository commands, indexes the output and answers queries against it in one call.
2. Process with ctx_execute or ctx_execute_file, and print only the answer.
3. For web content, call ctx_fetch_and_index(url, source) and then ctx_search(queries), so raw HTML never enters context.
4. Search with ctx_search, and put related questions into a single queries array.

The same rules block curl, wget and inline HTTP one-liners such as node -e "fetch(...)". They also tell the agent to write artifacts to files and return a path with a one-line description instead of dumping the content inline. A native file read is still correct when an edit needs the exact bytes in the conversation.

You keep prompting the way you normally do. A request like "run the test suite and tell me which tests fail" should become a sandboxed script. The main skill's shell reference shows this pattern for builds, tsc and tests: write the output to a temp file, grep for errors, report counts and file paths, then delete the file. To see whether routing is saving context, run /context-mode:ctx-stats. It reports tokens consumed per tool and the savings ratio. Slash commands only exist in Claude Code. On other platforms, type ctx stats or ctx doctor in the chat and the model calls the MCP tool.

Platform differences and setup gotchas

Support varies across the platforms the README lists. Session continuity needs five hooks working together. Full capture, snapshot and restore works on Claude Code, Gemini CLI, VS Code Copilot, JetBrains Copilot, OpenCode and KiloCode. GitHub Copilot CLI gets separate treatment, documented in docs/platform-support.md.

Kiro has partial coverage. Its native preToolUse and postToolUse hooks enforce sandbox routing and capture tool events. agentSpawn, Kiro's equivalent of SessionStart, is not implemented yet, so session restore is limited, and you have to copy KIRO.md into your project by hand. Antigravity and Zed have no hooks and no session support. On those, you copy GEMINI.md or AGENTS.md into the project root yourself.

Other setup details from the README:

• For Codex CLI, install with npm install -g context-mode and then add the config block to ~/.codex/config.toml.
• The Cursor Marketplace plugin is still awaiting review by the Cursor team. Until it is listed, install from a local folder. On Windows, Cursor does not follow symlinks or junctions, so the README copies the files with robocopy.
• On older glibc systems (CentOS 7/8, RHEL 8, Debian 10), the prebuilt better-sqlite3 binaries do not load. The module falls back to building from source with prebuild-install || node-gyp rebuild --release.
• If you want the ctx_* tools in Antigravity CLI without the plugin or hooks, add context-mode to ~/.gemini/config/mcp_config.json.

Setting permission rules

The README describes allow and deny rules written as Tool(what to match), where * matches anything. Its example deny list contains Bash(sudo *), Bash(rm -rf /*), Read(.env) and Read(**/.env*). Commands chained with &&, ; or | are split, and each part is checked on its own. That means echo hello && sudo rm -rf /tmp is blocked because the sudo part matches a deny rule. When rules conflict, deny always wins over allow.