issue-triage: enable noop reporting, add MCP warning guidance

[Copilot]

The triage agent was timing out (10 min) on a misleading startup warning — ! 2 MCP servers were blocked by policy — even though tools registered successfully. It spent the entire window debugging infrastructure instead of triaging.

Changes

• noop.report-as-issue: true — tool-call failures now surface as trackable GitHub issues instead of being silently swallowed.
• Agent instruction note — added a blockquote immediately after the HTML comment preamble telling the agent to ignore the "blocked by policy" startup warning and proceed; fall back to noop only on actual runtime tool failure.

Original prompt

Update .github/workflows/issue-triage.md with two changes:

1. Enable noop issue reporting (front-matter)

Change noop.report-as-issue from false to true so tool-call failures are tracked as issues:

# Before
  noop:
    report-as-issue: false

# After
  noop:
    report-as-issue: true

2. Add agent instruction to ignore the MCP "blocked by policy" startup warning

The agent currently times out (10 min) when it sees the startup warning ! 2 MCP servers were blocked by policy: 'github', 'safeoutputs' because it assumes the tools are unavailable and spends all its time debugging infrastructure. The tools actually register successfully — the warning is misleading.

Add a concise instruction at the top of the agent prompt body (after the --- frontmatter closing fence, before the existing # Agentic Triage heading or as a note after it) telling the agent to ignore this warning and proceed. For example:

> **Note:** Ignore any startup warning about MCP servers being "blocked by policy" — tools are available. If a tool call fails at runtime, call `noop` and exit; do not debug the infrastructure.

Place it just after the # Agentic Triage heading and the existing HTML comment on line 60, so it reads naturally as a preamble before the numbered steps.

The file to edit is .github/workflows/issue-triage.md.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for this failing job. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: I'll fetch the job logs right away!

Assistant: Let me pull up the workflow file for more context.

Assistant: The job failed due to a 10-minute timeout on the Execute GitHub Copilot CLI step. Here's what happened and how to fix it:

---

Root Cause

The logs show an early warning at startup:

! 2 MCP servers were blocked by policy: 'github', 'safeoutputs'

This caused the agent to believe the MCP tools were unavailable and it spent the entire 10-minute window trying to debug the infrastructure — checking log files, inspecting configs, attempting curl calls — instead of performing its actual triage task.

The irony is that both MCP servers actually registered successfully (visible in the debug logs dumped at timeout):

Tool registration complete: 2 succeeded, 0 failed, total tools=17

The early "blocked by policy" warning was a transient/misleading message; the tools were fully available by the time the agent started running.

---

Solution

The agent prompt in the workflow needs to be updated to:

1. Ignore the "blocked by policy" warning and proceed with the task — the agent should verify tool availability by attempting to use them rather than assuming unavailability from a startup warning.
2. Set a clear fallback strategy: if a tool call genuinely fails, signal via noop and exit — don't enter a debugging loop.

Here's a suggested addition to the agent prompt in your workflow file:

- name: Execute GitHub Copilot CLI
  # In your 'prompt' or 'instructions' field:
  prompt: |
    ...existing instructions...

    IMPORTANT: You may see a startup warning that MCP servers were "blocked by policy".
    Ignore this warning and proceed with your task immediately — the tools are available.
    Verify tool availability only by attempting to use them. If a tool call fails,
    call `noop` to signal completion and stop. Do NOT attempt to debug the infrastructure
    or inspect log files; that is outside the scope of your task.

Additionally, if the ! 2 MCP servers were blocked by policy message is coming from an early MCP registry policy check that returns a 401 (as seen in the logs), you should investigate whether the GITHUB_TOKEN or MCP server token passed to the workflow has sufficient permissions to pass the registry policy check, to eliminate the warning entirely.

User: Make a PR to add that with concise wording, and re-enable the noop issue so I can keep track of failures to call tools.

Assistant: The workflow file content is excluded by policy, so I can't read it directly. Let me search for the relevant pieces I need.

Assistant: Now I have everything I need. I'll make the two changes to issue-triage.md:

1. Add a startup instruction to ignore the "blocked by policy" warning and proceed immediately.
2. Change noop.report-as-issue from false to true.

Assistant: I'm waiting for your response to the confirmation dialog to proceed with creating the pull request.

This pull request was created from Copilot chat.

[heaths]

Actually, let's wait until #4257 is merged and see if this is even a problem still. That PR should take care of it.

[Copilot]

Pull request overview

Updates the agentic issue triage workflow source prompt/config to reduce wasted time on a misleading MCP startup warning and to make tool-call failures trackable via GitHub issues.

Changes:

• Enable noop.report-as-issue: true so tool-call failures can be surfaced as issues.
• Add an instruction note telling the agent to ignore the misleading “blocked by policy” startup warning and proceed, only falling back to noop on actual tool failure.

[Copilot]

The runtime workflow is .github/workflows/issue-triage.lock.yml (generated by gh aw compile). This change to noop.report-as-issue (and the new prompt note) won’t take effect unless the lock file is regenerated and committed; currently the lock file still has "report-as-issue":"false" in its Safe Outputs config. Please run gh aw compile and include the resulting issue-triage.lock.yml update in this PR.