[BUG]: actions/labeler interference with restricted-paths-guard.yml workflow #1967

This note summarizes the investigation into why PR #1965 showed:

• github-actions[bot] added Needs-Restricted-Paths-Review
• then immediately removed Needs-Restricted-Paths-Review
• while also adding cuda.bindings and cuda.core

Bottom line

There is no code path in .github/workflows/restricted-paths-guard.yml that removes Needs-Restricted-Paths-Review.

The workflow still has the intended sticky behavior:

• if review is needed and the label is absent, it adds the label
• if the label is already present, it leaves it in place
• it does not call gh pr edit --remove-label

So the removal appears to be coming from a different label-managing workflow, most likely .github/workflows/pr-auto-label.yml, which uses actions/labeler.

Evidence

1. restricted-paths-guard.yml does not remove the label

The live main copy of .github/workflows/restricted-paths-guard.yml only adds the label or leaves it in place:

• it sets LABEL_ACTION="added" after gh pr edit ... --add-label
• or it sets LABEL_ACTION="left in place (manual removal required)"
• there is no --remove-label anywhere in that workflow

That means the sticky-label behavior was not accidentally removed there.

2. The issue events show add, then remove, then module labels

For PR #1965, GitHub issue events show this exact sequence at 2026-04-22T20:46:11Z:

1. labeled -> Needs-Restricted-Paths-Review
2. unlabeled -> Needs-Restricted-Paths-Review
3. labeled -> cuda.bindings
4. labeled -> cuda.core

All four events were attributed to github-actions[bot].

The ordering matters: the Needs-Restricted-Paths-Review add happened first, and the remove happened immediately afterward in the same second.

3. The workflows running at that exact time were:

• CI: Restricted Paths Guard run 24801785023
• CI: Auto-label PRs by path run 24801785008
• CI: Enforce assignee/label/milestone on PRs run 24801785059

Of those three:

• restricted-paths-guard.yml can add Needs-Restricted-Paths-Review
• pr-metadata-check.yml does not edit labels
• pr-auto-label.yml applies labels using actions/labeler

This leaves pr-auto-label.yml / actions/labeler as the likely source of the removal.

4. pr-auto-label.yml uses actions/labeler

The workflow is:

• file: .github/workflows/pr-auto-label.yml
• action: actions/labeler@634933edcd8ababfe52f92936142cc22ac488b1b (v6.0.1)

Its label rules live in .github/labeler.yml, and for this PR they match:

• cuda.bindings for cuda_bindings/**
• cuda.core for cuda_core/**

That lines up exactly with the labels that were added at the same time the restricted-paths label disappeared.

5. The actions/labeler log says sync-labels: false

The CI: Auto-label PRs by path run log includes:

sync-labels: false

In theory, that setting should mean labeler does not remove labels.

However, there are historical reports/issues against actions/labeler where labels were still removed despite sync-labels: false, or where labels not defined in labeler.yml were still affected.

So the observed behavior is surprising, but not unprecedented.

Current conclusion

My current best explanation is:

1. restricted-paths-guard.yml correctly added Needs-Restricted-Paths-Review
2. pr-auto-label.yml / actions/labeler then removed it while applying the module labels

So this looks like interference from actions/labeler, not a bug in the sticky-label logic inside restricted-paths-guard.yml.

Practical implication

If we want Needs-Restricted-Paths-Review to remain sticky and avoid interference from unrelated label automation, then actions/labeler in .github/workflows/pr-auto-label.yml is the first place I would look to change or replace.

The safest direction would likely be to use an add-only module-labeling step that never removes labels it does not own.