Agents shouldnt mention on-disk data sources

[strawgate]

Reviewed /tmp/pr-context/review_comments.json for PR #822 and found no unresolved review threads (22 total, 0 unresolved). No additional code changes were needed, so nothing was pushed and no thread resolutions were pending from this run. Tests were not re-run because the branch content was unchanged in this pass.

it shouldnt mention that in its reply that it found the review comments in a json file on disk

[github-actions]

TL;DR: This issue is valid—current prompt sources explicitly teach agents to use /tmp/pr-context/* files and then post user-facing comments, but they do not forbid exposing those local paths, so path leakage is expected.

Recommendation

Add a shared response-hygiene rule in .github/workflows/gh-aw-fragments/pr-context.md (preferred single insertion point) that local runtime paths are internal-only and must not be named in user-visible comments/reviews; use semantic phrasing like “review threads” or “PR context” instead.

Findings

• .github/workflows/gh-aw-fragments/pr-context.md:134 instructs agents to use /tmp/pr-context/ as primary source.
• .github/workflows/gh-aw-mention-in-pr.md:127,147,155,167,174 repeatedly instructs reading /tmp/pr-context/... files including review_comments.json.
• .github/workflows/gh-aw-mention-in-pr.md:195 then instructs posting a user-facing comment (add_comment) with no prohibition on mentioning those internal file paths.
• .github/workflows/gh-aw-mention-in-pr.md:12 and .github/workflows/gh-aw-pr-review.md:11 both import gh-aw-fragments/pr-context.md, so fragment-level guidance propagates broadly.
• Related change history confirms origin: PR #445 introduced the pre-fetched /tmp/pr-context pattern and wiring.

Verification

I verified with repository search (source .md files):

rg -n "PR context on disk|/tmp/pr-context/review_comments\.json|call `add_comment` with your response" .github/workflows/gh-aw-mention-in-pr.md
rg -n "PR data is pre-fetched to `/tmp/pr-context/`" .github/workflows/gh-aw-fragments/pr-context.md
rg -n "`/tmp/pr-context/review_comments\.json`" .github/workflows/gh-aw-fragments/review-process.md

Matches confirm internal /tmp/pr-context paths are explicit inputs in prompt text and no user-output redaction rule is present at those response points.

Detailed Action Plan

1. Add shared guardrail in .github/workflows/gh-aw-fragments/pr-context.md directly under the ## PR Context guidance (near line 134):
   • “In user-visible comments/reviews, do not mention local filesystem paths or filenames (e.g., /tmp/pr-context/*); describe data sources semantically (review threads, PR metadata, linked issues).”
2. Optionally reinforce in .github/workflows/gh-aw-mention-in-pr.md near Step 3 response (around line 195) with one short reminder for user-facing output hygiene.
3. Regenerate lockfiles (make compile) so all compiled workflows inherit the new prompt rule.
4. Validate with make lint and a prompt-text grep check ensuring the new guardrail appears in affected compiled lockfiles.

Related Items

Type	Link	Relevance
Issue	#494	Current report: user-visible reply exposed /tmp/pr-context/review_comments.json
PR	#445	Introduced pre-fetched PR context on disk and prompt wiring
Issue	#444	Earlier pattern discussing on-disk context files in prompts
File	.github/workflows/gh-aw-fragments/pr-context.md:134	Shared source where internal context usage is defined
File	.github/workflows/gh-aw-mention-in-pr.md:127,147,195	Reads disk context and posts user-facing comment
File	.github/workflows/gh-aw-fragments/review-process.md:17,47	Reinforces review_comments.json usage

---

What is this? | From workflow: Issue Triage

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.