From d6c5e5ea02a8957958235ae4e13f3d6a5aa77544 Mon Sep 17 00:00:00 2001
From: "renovate[bot]" <29139614+renovate[bot]@users.noreply.github.com>
Date: Fri, 17 Jul 2026 13:16:51 +0000
Subject: [PATCH 1/2] chore(deps): update dependency octocode-mcp to v16

---
 npx/octocode-mcp/spec.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/npx/octocode-mcp/spec.yaml b/npx/octocode-mcp/spec.yaml
index f40e8caa..b9d2eaa8 100644
--- a/npx/octocode-mcp/spec.yaml
+++ b/npx/octocode-mcp/spec.yaml
@@ -12,7 +12,7 @@ metadata:
 
 spec:
   package: "octocode-mcp"
-  version: "15.0.2"
+  version: "16.0.0"
 
 provenance:
   # Monorepo with multiple packages; npm versions don't match git tags

From 2d3b87726e36067685806fab84dc34b32a16d5dd Mon Sep 17 00:00:00 2001
From: Dan Barr <6922515+danbarr@users.noreply.github.com>
Date: Fri, 17 Jul 2026 09:44:37 -0400
Subject: [PATCH 2/2] chore: allowlist AITech-8.2 for octocode-mcp v16
 search/browse tools

ghSearchCode and localViewStructure trip the scanner's data-exfiltration
heuristic on new v16 wording (cache/clone/materialize phrasing), but both
are read-only tools inherent to this server's purpose. The equivalent
tools in v15.0.2 passed cleanly, and the scan's LLM analyzer found no
corroborating issue.
---
 npx/octocode-mcp/spec.yaml | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/npx/octocode-mcp/spec.yaml b/npx/octocode-mcp/spec.yaml
index b9d2eaa8..0c2bef7d 100644
--- a/npx/octocode-mcp/spec.yaml
+++ b/npx/octocode-mcp/spec.yaml
@@ -18,3 +18,17 @@ provenance:
   # Monorepo with multiple packages; npm versions don't match git tags
   repository_uri: "https://github.com/bgauryy/octocode-mcp"
   repository_ref: "refs/heads/main"
+
+security:
+  allowed_issues:
+    - code: "AITech-8.2"
+      reason: |
+        Flagged on ghSearchCode and localViewStructure, both read-only search/browse
+        tools that return results to the calling agent. This is inherent to
+        octocode-mcp's purpose as a GitHub + local code discovery server. The
+        equivalent tools in v15.0.2 (githubSearchCode, localViewStructure) exposed
+        the same read capability and passed the scan cleanly with 0 findings; the
+        v16.0.0 wording changes add local caching/proof-of-work phrasing (e.g.
+        "cache fetch", "clone", "structured entries[] output") that trips the YARA
+        heuristic without introducing a new data path. The scan's LLM analyzer,
+        run in the same pass, found no corroborating issue on either tool.