Fix copilot assignment in create_issue by adding missing environment variable

[Copilot]

The GH_AW_ASSIGN_COPILOT environment variable wasn't being set in the unified safe outputs handler, causing copilot assignment to be skipped.

Root Cause

When workflows used assignees: copilot in their safe-outputs.create-issue configuration, the copilot assignment step was being skipped because the GH_AW_ASSIGN_COPILOT environment variable wasn't set. The create_issue.cjs handler checks for this variable to determine whether to queue issues for copilot assignment.

Changes

Fixed copilot assignment environment variable (pkg/workflow/compiler_safe_outputs_env.go)

Added logic to set GH_AW_ASSIGN_COPILOT: "true" when copilot is in assignees:

// Check if copilot is in assignees - if so, we'll output issues for assign_to_agent job
if hasCopilotAssignee(cfg.Assignees) {
    *steps = append(*steps, "          GH_AW_ASSIGN_COPILOT: \"true\"\n")
    compilerSafeOutputsEnvLog.Print("Copilot assignment requested - will output issues_to_assign_copilot")
}

Added comprehensive tests (pkg/workflow/compiler_safe_outputs_env_copilot_test.go)

• Test env var is set when copilot is in assignees
• Test env var is not set when copilot is absent
• Test mixed assignees scenario (copilot + other users)
• Test nil assignees edge case
• Test empty assignees edge case

Impact

Workflows that use assignees: copilot in their safe-outputs.create-issue configuration now correctly queue created issues for copilot assignment:

safe-outputs:
  create-issue:
    max: 1
    assignees: copilot  # Assignment now works correctly

The compiled workflows now include:

env:
  GH_AW_ASSIGN_COPILOT: "true"

Workflows using assignees (security-alert-burndown, duplicate-code-detector, breaking-change-checker) now have the environment variable set correctly and copilot assignment works as intended.

Testing

• ✅ All 5 copilot assignment tests pass
• ✅ All existing create_issue tests pass
• ✅ Unit test suite passes
• ✅ All 142 workflows recompiled with correct environment variable
• ✅ Security scan passed (0 alerts)

Original prompt

Fix validation error when assigning issue to copilot in security alert burndown campaign:
{
"body": "## Context\nThis issue tracks Dependabot PR bundling work discovered by the Security Alert Burndown campaign.\n\n## Bundling Rules\n- Group work by runtime. Never mix runtimes.\n- Group changes by target dependency file (one manifest + its lockfile).\n- Patch/minor updates may be bundled; major updates should be isolated unless tightly coupled.\n- Bundled releases must include a research report (packages, versions, breaking changes, migration, risk, tests).\n\n## Planned Bundles\n\n### Node.js — actions/setup/js/package.json\nPRs:\n- [ ] #12017 - Bump @vitest/coverage-v8 from 4.0.17 to 4.0.18 (patch update)\n- [ ] #12016 - Bump @types/node from 25.0.9 to 25.0.10 (patch update)\n- [ ] #12014 - Bump prettier from 3.8.0 to 3.8.1 (patch update)\n- [ ] #12011 - Bump @vitest/ui from 4.0.17 to 4.0.18 (patch update)\n\nBundle recommendation: All are patch updates to testing/dev tools in the same manifest. Can be safely bundled.\n\n### Node.js — actions/setup/js/package.json (major update - separate)\nPRs:\n- [ ] #12012 - Bump @actions/github from 7.0.0 to 8.0.0 (major update)\n\nBundle recommendation: Major version update should be isolated. Research breaking changes before merging.\n\n### Node.js — docs/package.json\nPRs:\n- [ ] #12015 - Bump astro from 5.16.12 to 5.16.15 (patch update)\n- [ ] #12013 - Bump @astrojs/starlight from 0.37.3 to 0.37.4 (patch update)\n- [ ] #12010 - Bump @playwright/test from 1.57.0 to 1.58.0 (minor update)\n\nBundle recommendation: Documentation tooling updates in same manifest. Can be bundled together.\n\n### Node.js — .github/workflows dependencies\nPRs:\n- [ ] #12099 - Bump hono from 4.11.4 to 4.11.7 (patch update with security fixes)\n- [ ] #12009 - Bump @sentry/mcp-server from 0.27.0 to 0.29.0 (minor update)\n\nBundle recommendation: Both are workflow runtime dependencies. Security fix should be prioritized but can be bundled with the Sentry update.\n\n## Agent Task\n1. For each bundle section above, research each update for breaking changes and summarize risks.\n2. Bundle PRs per section into a single PR (one runtime + one manifest).\n3. Ensure CI passes; run relevant runtime tests.\n4. Add the research report to the bundled PR.\n5. Update this issue checklist as PRs are merged.",
"temporary_id": "aw_sec2026012901",
"title": "Security Alert Burndown: Dependabot bundling plan (2026-01-29)",
"type": "create_issue"
}

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[mnkiefer]

@copilot This was already possible before

[Copilot]

@copilot This was already possible before

You're absolutely right! The assignees field was already fully functional - it was implemented in the Go config, JavaScript handler, and had tests.

My change only adds validation for the field (ensuring it's an array of strings with max 39 chars each), but doesn't enable any new functionality. The feature was working before, just without explicit validation in the schema.

Should I close this PR since it's not actually fixing a bug, just adding validation? Or would you prefer to keep it for the added safety of validating assignee format?

[mnkiefer]

@copilot No, but check my the json snippet I provided would cause a validation error and skip the agent assignment step

[Copilot]

@copilot No, but check my the json snippet I provided would cause a validation error and skip the agent assignment step

I'm looking at the JSON snippet from the problem statement - it's a create_issue message without an assignees field. The validation schema only validates fields that are present in the message, so a missing assignees field wouldn't cause a validation error.

The assignees: copilot in the workflow config is applied by the handler as a default to all created issues, not validated against the agent output.

Could you clarify what specific validation error you're seeing? Is it:

1. An error when the agent output is missing assignees?
2. An error when the agent output includes assignees?
3. Something else I'm missing?

I want to make sure I fix the actual issue you're encountering.

[mnkiefer]

@copilot assignment is skipped with the json smippet the agent provided.

[Copilot]

@copilot assignment is skipped with the json smippet the agent provided.

I've traced through the code and the JSON snippet should work correctly:

1. The workflow config has assignees: copilot which compiles to "assignees":["copilot"] in the handler config
2. The agent output doesn't include assignees field - which is correct since it comes from the config
3. The handler merges config assignees with message assignees, finds "copilot", and queues the issue for assignment

My validation change adds the assignees field as an optional array field. It doesn't reject messages without assignees, and it preserves the config-based assignment.

Could you share:

1. The actual error message or log output showing the assignment being skipped?
2. Or the specific workflow run where this is happening?

This will help me understand what's actually going wrong so I can fix the right issue.

[mnkiefer]

@copilot No error, but the step was skipped.

[Copilot]

@copilot No error, but the step was skipped.

I found the root cause! The issue is NOT related to my validation change. There's a bug in the compiler where GH_AW_ASSIGN_COPILOT environment variable isn't being set in the unified safe outputs handler step.

The compiler checks if "copilot" is in assignees (line 179 in create_issue.go) and should set the env var, but addAllSafeOutputConfigEnvVars() doesn't actually add it - it only adds GH_AW_SAFE_OUTPUTS_STAGED.

This means copilot assignment has been broken since the unified safe outputs handler was introduced, regardless of my validation changes.

My validation PR is unrelated to this issue. Should I:

1. Close this PR (validation isn't the problem)
2. Keep it (validation still adds safety) and file a separate issue for the copilot assignment bug?

[mnkiefer]

@copilot fix the underlying issue

[Copilot]

@copilot fix the underlying issue

Fixed in commits 41c135a and 95804da.

The issue was that GH_AW_ASSIGN_COPILOT wasn't being set in the unified safe outputs handler. Added the logic to compiler_safe_outputs_env.go to check for copilot in assignees and set the env var accordingly.

Now when workflows have assignees: copilot, the compiled workflow includes:

env:
  GH_AW_ASSIGN_COPILOT: "true"

This enables the create_issue.cjs handler to queue issues for copilot assignment. The original validation fix (assignees field) is also included for safety.

[mnkiefer]

@copilot Only keep the fix, discard the extra validation you added, and recompile workflows

[Copilot]

@copilot Only keep the fix, discard the extra validation you added, and recompile workflows

Done in commit e48d3d1.

Reverted the validation schema changes from safe_output_validation_config.go. Kept only:

• The GH_AW_ASSIGN_COPILOT env var fix in compiler_safe_outputs_env.go
• The 5 comprehensive tests in compiler_safe_outputs_env_copilot_test.go
• Recompiled all 142 workflows

The workflows now have GH_AW_ASSIGN_COPILOT: "true" set correctly and copilot assignment will work.