Compiler drops 'blocked' constraints from safe-outputs configs inconsistently

[benvillalobos]

Summary

When compiling a workflow with blocked constraints on safe-outputs (e.g. assign-to-user, unassign-from-user, add-labels), the compiler inconsistently distributes the blocked field between the two generated configs:

1. config.json (MCP server validation during agent execution)
2. GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG (handler job, last line of defense before writes)

Steps to Reproduce

1. Define a workflow with blocked on multiple safe-outputs:

   safe-outputs:
     add-labels:
       target: "*"
       target-repo: "microsoft/vscode"
       max: 5
       blocked: ["[*]*", "~spam", "stale", "triage-needed"]
     assign-to-user:
       target: "*"
       target-repo: "microsoft/vscode"
       max: 1
       blocked: [copilot, "*[bot]"]
     unassign-from-user:
       target: "*"
       target-repo: "microsoft/vscode"
       max: 2
       blocked: [copilot, "*[bot]"]

2. Run gh aw compile
3. Inspect the generated .lock.yml

Expected Behavior

Both config.json and GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG should include the blocked constraint for all safe-output types that define it.

Actual Behavior

The blocked constraint is split inconsistently:

Config	add_labels.blocked	assign_to_user.blocked	unassign_from_user.blocked
config.json (MCP server)	❌ missing	✅ present	✅ present
HANDLER_CONFIG (handler job)	✅ present	❌ missing	❌ missing

Security Impact

The GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG is the last line of defense before writes are applied to the GitHub API. Since the agent job has broad filesystem access, it could theoretically bypass MCP server validation by writing safe-output entries directly. The handler config should enforce all constraints defined in the workflow .md source, including blocked for assign/unassign operations.

Similarly, config.json should enforce blocked for add_labels to provide defense-in-depth during agent execution.

Environment

• gh aw version: v0.50.0
• OS: Windows
• Workflow: issue-triage.md in microsoft/vscode-engineering

Workaround

Manually patch the .lock.yml after compilation to add the missing blocked fields to both configs.

[benvillalobos]

Update: Root Cause Identified — Tool Name Mismatch

Further investigation revealed the actual root cause of the flaky safe-output failures.

The Problem

The prompt injected into the agent lists unprefixed tool names:

xml <safe-output-tools> Tools: add_labels, remove_labels, assign_to_user, unassign_from_user, missing_tool, missing_data </safe-output-tools>

But the MCP gateway registers tools with the server name prefix (safeoutputs-):

• safeoutputs-add_labels
• safeoutputs-remove_labels
• safeoutputs-assign_to_user
• etc.

Agent Log Evidence

From failed run 22344595895:

`
All labels verified. Now applying all triage results using safe-output tools.

✗ add_labels
Tool 'add_labels' does not exist.

✗ remove_labels
Tool 'remove_labels' does not exist.

✗ assign_to_user
Tool 'assign_to_user' does not exist.
`

The agent tries to call add_labels (as instructed by the prompt) but the tool is registered as safeoutputs-add_labels. Sometimes the model figures out the prefix mapping; sometimes it doesn't — explaining the intermittent nature.

Source

The <safe-output-tools> section is generated by the compiler (line 122-124 of the compiled lock file). The tools.json also uses unprefixed names ("name": "add_labels"). But the MCP server is registered as "safeoutputs" in the MCP config, so the gateway prefixes all tools with safeoutputs-.

Suggested Fix

The compiler should emit prefixed tool names in the <safe-output-tools> prompt section to match what the MCP gateway actually registers:

xml <safe-output-tools> Tools: safeoutputs-add_labels, safeoutputs-remove_labels, safeoutputs-assign_to_user, safeoutputs-unassign_from_user, safeoutputs-missing_tool, safeoutputs-missing_data </safe-output-tools>

Workaround

Users can add explicit prefixed tool names in their .md workflow prompt. We're applying this workaround now.