Repo Assist creates duplicate monthly activity issues when search_issues results are DIFC-filtered

[mlinksva]

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:

1. The backend/gateway finds the already-open monthly issues.
2. Those same issues are then DIFC-FILTERED from the agent.
3. 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:

1. The gateway returned existing open monthly issues for the search query.
   For example, responses included open [Repo Assist] Monthly Activity 2026-03 issues such as:

   • [Repo Assist] Monthly Activity 2026-03 licensee/licensee#941
   • [Repo Assist] Monthly Activity 2026-03 licensee/licensee#954
   • [Repo Assist] Monthly Activity 2026-03 licensee/licensee#955

2. The GitHub MCP log then recorded those same issues as DIFC-FILTERED, for example:

   • issue:licensee/licensee#941
   • issue:licensee/licensee#954
   • issue:licensee/licensee#955

   with messages like:

   • Resource 'issue:licensee/licensee#941' has lower integrity than agent requires
   • Agent would need to drop integrity tags [...] to trust this resource

3. 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

4. The run then called create_issue and created:

   • [Repo Assist] Monthly Activity 2026-03 licensee/licensee#956

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_issues finds 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-03 issue instead of updating the existing one

Questions

1. Was there an intentional trust / DIFC change between the runtime stack using GitHub MCP v0.31.0 and the one using v0.32.0 that would explain this?
2. Should issues previously created by Repo Assist / github-actions[bot] be readable as trusted inputs for subsequent Repo Assist runs in the same repository?
3. Should gh-aw surface a stronger error when all matching search_issues results 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:
  • https://github.com/licensee/licensee/actions/runs/23409407003
  • https://github.com/licensee/licensee/actions/runs/23453592817
• Repo-side workflow/compiler upgrade context:
  • licensee/licensee@52592e1
• gh-aw in compiled workflow after that point: v0.61.2
• GitHub MCP observed in logs:
  • good run: v0.31.0
  • broken runs: v0.32.0

[lpcox]

@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?