fix(review): defang grounding file paths

[JSONbored]

Motivation

• Grounding now includes newly added files and previously-rendered grounding sections interpolated file.path directly into the reviewer prompt, allowing attacker-controlled filenames to inject prompt-like text into the AI prompt.
• The change neutralizes/escapes attacker-controlled path text so malicious filenames cannot create new prompt lines or embed reviewer instructions.

Description

• Add safeGroundingPath(path: string) which calls neutralizePromptInjection(path).text and escapes CR/LF to keep line breaks as data.
• Use the sanitized path in formatFilesSection for both inline and truncated file renderings so headings no longer contain raw filenames.
• Add unit regression tests that cover inline and truncated grounding entries with prompt-like added-file names.
• Files changed: src/review/review-grounding.ts and test/unit/review-grounding.test.ts.

Testing

• Ran git diff --check which reported no issues.
• Ran the unit suite for the modified file with npx vitest run test/unit/review-grounding.test.ts --pool=forks --reporter=dot and all tests in that file passed (24 passed).
• Ran type checking with npm run typecheck and it succeeded.
• Attempted coverage npx vitest run ... --coverage but the local coverage provider errored with TypeError: jsTokens is not a function so full coverage collection could not be completed locally.
• Attempted npm audit --audit-level=moderate but the registry audit endpoint returned 403 Forbidden, preventing completion of the dependency audit step.

---

Codex Task

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@cd8adb4). Learn more about missing BASE report.
⚠️ Report is 34 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4075   +/-   ##
=======================================
  Coverage        ?   93.56%           
=======================================
  Files           ?      381           
  Lines           ?    35477           
  Branches        ?    13010           
=======================================
  Hits            ?    33195           
  Misses          ?     1621           
  Partials        ?      661           

Files with missing lines	Coverage Δ
src/review/review-grounding.ts	93.10% <100.00%> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-07 23:51:32 UTC}

2 files · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · clean

⏸️ Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
This is a narrow, well-targeted fix for a real prompt-injection gap: `formatFilesSection` in src/review/review-grounding.ts previously interpolated `file.path` raw into the `### {path}` heading, so an attacker-controlled filename (e.g. one containing embedded newlines and instruction-like text) could inject new prompt lines into the grounding block fed to the reviewer model. `safeGroundingPath` closes this by routing the path through the same `neutralizePromptInjection` used for file bodies and then escaping CR/LF so embedded line breaks stay inert as `\r`/`\n` literals rather than creating new lines — applied consistently to both the inline and truncated render branches, the two places `file.path` was previously interpolated raw. The two new tests exercise the real `formatGroundingSections` → `formatFilesSection` path with realistic added-file inputs (newline-containing paths, which GitHub tree entries can technically carry) rather than a fabricated scenario, so they're real regression coverage, not can't-occur padding.

Nits — 5 non-blocking

• The PR description doesn't link an open issue for this security fix — per repo convention every contributor PR should close/reference one; worth confirming there's a tracking issue even for a security-motivated change.
• safeGroundingPath (review-grounding.ts:196) only escapes `\r`/`\n`; other unicode line-separator characters (U+2028/U+2029) that some renderers treat as line breaks pass through untouched — worth confirming neutralizePromptInjection already strips those, or note it's out of scope for this fix.
• Coverage tooling failed locally (`jsTokens is not a function`) per the PR's own testing notes, so patch-coverage% wasn't verified locally; worth confirming codecov/patch (shown PASSED in CI) actually covers both new branches in formatFilesSection (truncated vs inline) — the diff and tests suggest it does, but it's unverified from the description alone.
• Consider hoisting a small shared helper (or reusing safeGroundingPath) if any other module in the grounding/review-prompt pipeline also interpolates `PullRequestFile.filename`/`ChangedFileContent.path` directly — worth a quick grep across review-grounding.ts callers to confirm this was the only interpolation site.
• The escaping choice of literal `\r`/`\n` text (vs. e.g. stripping) is good since it keeps the data visible-but-inert; just confirm downstream consumers of the rendered grounding block never re-parse it in a way that could reinterpret `\n` as a real newline.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 51 registered-repo PR(s), 43 merged, 503 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 51 PR(s), 503 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, JavaScript, Ruby, Go, Kotlin, MDX, Shell
• Official Gittensor activity: 51 PR(s), 503 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review