Repository navigation
Repo Assist creates duplicate monthly activity issues when search_issues results are DIFC-filtered #22533
Description
In licensee/licensee, I observed a regression where Repo Assist started creating a new monthly activity issue on each scheduled run instead of updating the existing open one.
I asked Copilot to investigate and after back and forth what follows is its suggested issue.
The clearest boundary in the logs is not the repo-side workflow upgrade by itself, but the runtime change between:
- a last known good run using GitHub MCP
v0.31.0 - subsequent broken runs using GitHub MCP
v0.32.0
Why this is likely a bug
The key inconsistency is:
- The backend/gateway finds the already-open monthly issues.
- Those same issues are then
DIFC-FILTEREDfrom the agent. - The agent behaves as if no monthly issue exists and calls
create_issue.
So Repo Assist is not failing to search. It is finding the issue, but the issue is not visible at the point where the agent decides whether to update or create.
This leads to a false negative:
- search finds the issue
- filtering hides it
- agent assumes it does not exist
- agent creates a duplicate
Evidence
Last known good run
This run updated the existing monthly issue instead of creating a new one:
- Run: https://github.com/licensee/licensee/actions/runs/23260741102
- Existing monthly issue it updated: [Repo Assist] Monthly Activity 2026-03 licensee/licensee#941
Relevant logs from that run show:
- GitHub MCP server version
v0.31.0 - agent text:
Now I'll update the monthly summary issue #941
First broken run
This run created a duplicate monthly issue instead:
- Run: https://github.com/licensee/licensee/actions/runs/23385748544
- Duplicate issue created by that run: [Repo Assist] Monthly Activity 2026-03 licensee/licensee#956
Relevant behavior from that run:
-
The gateway returned existing open monthly issues for the search query.
For example, responses included open[Repo Assist] Monthly Activity 2026-03issues such as: -
The GitHub MCP log then recorded those same issues as
DIFC-FILTERED, for example:issue:licensee/licensee#941issue:licensee/licensee#954issue:licensee/licensee#955
with messages like:
Resource 'issue:licensee/licensee#941' has lower integrity than agent requiresAgent would need to drop integrity tags [...] to trust this resource
-
The agent sandbox log then reasoned as if nothing existed, with messages like:
No monthly activity issue was found ...Memory says "Monthly 2026-03 issue created" but the search returns nothing
-
The run then called
create_issueand created:
Later broken runs
The same pattern appears in later scheduled runs:
- https://github.com/licensee/licensee/actions/runs/23409407003
- https://github.com/licensee/licensee/actions/runs/23453592817
These also used GitHub MCP v0.32.0 and also created additional monthly duplicates rather than updating the existing open issue.
Expected behavior
If search_issues finds an existing issue that Repo Assist previously created and is expected to maintain, that issue should remain visible to the agent for update flows.
If integrity filtering intentionally prevents that, the tool result should fail in a way that is distinguishable from "no results", so the agent does not treat a filtered match as nonexistence.
Actual behavior
In the broken runs:
search_issuesfinds existing monthly issues at the backend/gateway layer- those issues are then
DIFC-FILTERED - the agent sees no usable monthly issue
- Repo Assist creates a fresh
[Repo Assist] Monthly Activity 2026-03issue instead of updating the existing one
Questions
- Was there an intentional trust / DIFC change between the runtime stack using GitHub MCP
v0.31.0and the one usingv0.32.0that would explain this? - Should issues previously created by Repo Assist /
github-actions[bot]be readable as trusted inputs for subsequent Repo Assist runs in the same repository? - Should
gh-awsurface a stronger error when all matchingsearch_issuesresults are filtered, so the agent does not interpret that as "not found"?
Environment
- Repo: https://github.com/licensee/licensee
- Good run: https://github.com/licensee/licensee/actions/runs/23260741102
- First broken run: https://github.com/licensee/licensee/actions/runs/23385748544
- Later broken runs:
- Repo-side workflow/compiler upgrade context:
gh-awin compiled workflow after that point:v0.61.2- GitHub MCP observed in logs:
- good run:
v0.31.0 - broken runs:
v0.32.0
- good run:
Activity
fix(rust-guard): handle GraphQL-format search results and bot-author …
test(rust-guard): add regression tests for github/gh-aw#22533
fix(rust-guard): handle GraphQL-format search results and bot-author …
lpcox commentedon Mar 24, 2026
@mlinksva could you modify your lock.yml file so that it uses container image ghcr.io/github/gh-aw-mcpg:v0.2.4 and re-run?
https://github.com/github/gh-aw/issues/22533#issuecomment-4115285684
mlinksva commentedon Mar 24, 2026
@lpcox modified lockfile per your instructions, and fixed! I enjoyed the below
mlinksva commentedon Mar 24, 2026
However, I note the most recent run (that added the note above) also added:
I haven't investigated yet, just noting in case it might be fallout from this change.
16 remaining items
mlinksva commentedon Mar 31, 2026
They're first time contributors to my repo, but not first time users of GitHub. My (probably wrong) understanding is that only the latter (first time users of GitHub) should be filtered out at
unapproved.mlinksva commentedon Apr 6, 2026
Belatedly noting that adding usernames as
trusted-usersdoes work, those specific users' issues are no longer filtered out.I'd still like some way to have issues that have some indication that they're not malicious (eg a maintainer has reacted/commented/labeled?) get past the inegrity filter for a user who hasn't contributed to the repo before -- without me manually adding the user to the config or opening up to any/all content.
lpcox commentedon Apr 7, 2026
@mlinksva Thanks for the update. Funny you should mention a maintainer endorsing a comment with a reaction. About a month ago, i spent a lost weekend trying to implement this only to realize that the github mcp server only gave reaction counts instead of info about who reacted to a comment. However, we are looking to move away from the github mcp server to a containerized/proxied gh cli, which could tell us if a maintainer had reacted positively to a comment, e.g., a thumbs up, heart, etc, as a form of endorsement. I think this will work if we can transition away from the mcp server.
mlinksva commentedon Apr 9, 2026
Nice, looking forward to it!
Just in case useful (I've no idea if they are related), a few potential oddities from the most recent run in licensee/licensee:
Error: ✗ Message 1 (add_labels) failed: No issue/PR number availableerror that I don't know what was caused by -- the summary below says it labeled 655 but there are no labels on it so must be about that onepelikhan commentedon Apr 10, 2026
Repo assist needs its own repo to track improvements
lpcox commentedon Apr 23, 2026
Tracking issue created in gh-aw-mcpg: github/gh-aw-mcpg#4419
This covers the guard-side fix: changing
author_association: NONEto map tounapprovedintegrity (instead ofnone) inguards/github-guard/rust-guard/src/labels/helpers.rs. This would allow established GitHub users who haven't previously contributed to a specific repo to passmin-integrity: unapprovedfiltering.