Repository navigation
fix(scanner): inspect only the scanned server's tools, keep peers as index context - #1812
Merged
Merged
Conversation
…index context (#1724) The per-tool change-gate scan (trust_mode: scan approval and the manual-mode hold evidence) fed every other connected server's tools to the detect engine as cross-server context, and Engine.Scan then ran every check — the phrase and bundle regex detection included — over the whole fleet for each held tool, discarding the peer findings afterwards. Every discovery pass rescans every still-held tool, so an install with a few hundred tools and a few dozen held changes burned tools x fleet every 5 minutes: 471 tools, 108 held, ~11 minutes at 100% CPU per pass on the reporting machine. detect.NewScopedRegistryView(targets, peers) puts only the targets in the scan set and indexes peers into ToolsByName/ToolNames, which is the only way a check (Shadowing) ever reads them. Target findings are identical to a full view's; peers are no longer normalized or inspected. Both scanner entry points (ScanToolMetadataVerdict, detectEngineFindings) use it. One held-tool scan against a 470-tool fleet: ~3 s -> ~5 ms (BenchmarkScanToolMetadataVerdict_PerToolWithPeers). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Deploying mcpproxy-docs with
|
| Latest commit: |
498fcf2
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://a69e59cc.mcpproxy-docs.pages.dev |
| Branch Preview URL: | https://claude-mcpproxy-high-cpu-idl.mcpproxy-docs.pages.dev |
Dumbris
enabled auto-merge (squash)
November 1, 2026 11:23
Contributor
📦 Build ArtifactsWorkflow Run: View Run Available Artifacts
How to DownloadOption 1: GitHub Web UI (easiest)
Option 2: GitHub CLI gh run download 41301136638 --repo smart-mcp-proxy/mcpproxy-go
|
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #1724 (core at >100% CPU while idle, battery drain).
Root cause. The per-tool change-gate scan (
Runtime.scanToolEvidence→scanner.ScanToolMetadataVerdict) feeds every other connected server's tools to the detect engine as cross-server context (needed by the shadowing/impersonation check), butEngine.Scanthen ran every check — phrase and bundle regex detection included — over the whole fleet for each held tool, and threw the peer findings away afterwards. Every 5-minute discovery pass re-evaluates every still-held (changed/pending) tool, so the cost isheld tools × fleet size × all checksper pass. The reporting install has 471 tools on 11 servers with 108 held changes: ~11 minutes at 100% CPU, then a 5-minute gap, forever.Fix.
detect.NewScopedRegistryView(targets, peers): only the scanned server's tools go into the scan set (Tools); peers are indexed intoToolsByName/ToolNames, which is the only way any check (Shadowing) reads them. Peers are no longer normalized or inspected. Target findings are identical to a full view's — the cross-server rug-pull tests still fire. Both scanner entry points (ScanToolMetadataVerdictanddetectEngineFindings) use it.Measured.
BenchmarkScanToolMetadataVerdict_PerToolWithPeers(11 servers, 43 tools each, one held tool per op) on an M4 Pro:Peer collection (
collectPeerToolMetadata, ~1.5 ms for 470 schemas) was measured and left as is: a pass with 108 held tools now spends well under a second every 5 minutes.Test plan
TestNewScopedRegistryView_InspectsTargetsOnly/_TargetFindingsMatchFullView(new, fail without the fix)go test ./internal/security/detect/... ./internal/security/scanner/...go test -race ./internal/security/detect/...go test ./internal/runtime/ -run 'Scan|Quarantine|Approval|Baseline|Peer|Shadow'golangci-lint run --config .github/.golangci.yml ./internal/security/...— 0 issues🤖 Generated with Claude Code