Put code-review-graph Behind a Read-Only MCP Boundary Before Connecting Your Repository

A developer warns that before connecting any code-intelligence MCP server like code-review-graph to an agent, the first integration should be read-only and proven with a canary. The developer recommends running the server as a separate OS user against a disposable checkout, denying network egress, and creating files that must and must not be visible to test the boundary. The acceptance rule is strict: the tool must index public canaries but not private ones, and must not modify files.

code-review-graph https://github.com/tirth8205/code-review-graph is trending because it promises a useful trade: build a persistent local map of a codebase so an AI reviewer reads relevant context instead of ingesting the whole repository. The repository is MIT-licensed and exposes MCP and CLI interfaces. That can reduce context. It can also create a high-value index of your source tree. Before connecting any code-intelligence MCP server to an agent, I would make the first integration read-only and prove the boundary with a canary. The assets are not only source files. The graph may reveal: The primary failure is authority creep: a context tool gains write, shell, or unrestricted filesystem access because the agent runtime grants every server the same permissions. Run the server as a separate OS user against a disposable checkout: useradd --system codegraph install -d -o codegraph -g codegraph /srv/codegraph/repo sudo -u codegraph git clone --depth=1 "$REPO URL" /srv/codegraph/repo chmod -R a-w /srv/codegraph/repo Then deny network egress and mount only the checkout plus a dedicated graph-data directory. Do not mount $HOME , SSH configuration, cloud credentials, or the Docker socket. Create files that must and must not be visible: src/public canary.ts SHOULD INDEX secrets/private canary.txt MUST NOT INDEX .git/config MUST NOT RETURN Add secrets/ to the tool's exclusion configuration. Ask the MCP client three questions: SHOULD INDEX . MUST NOT INDEX .The acceptance rule is strict: test 1 succeeds; tests 2 and 3 return no content. Also verify the server process cannot modify src/public canary.ts . Record tool name, requested path, decision, duration, and result size. Avoid logging full source fragments by default; otherwise the audit system becomes another copy of the repository. {"tool":"graph.query","scope":"src/ ","decision":"allow","bytes":1842} I have not audited the project's implementation or reproduced its published context-reduction examples. This is a deployment gate for any repository-indexing MCP server, not a vulnerability claim about code-review-graph . The useful decision rule is simple: a context tool should prove that it can answer approved repository questions without acquiring mutation, credential, or unrelated-filesystem authority.