Fix: GitHub Larger Runner Runner-Group Permissions

If a repository cannot reach your larger runner, the runner group access settings are usually the cause, and the default differs between enterprise and organization groups.

According to GitHub's docs, runner groups control which repositories can use a runner. Enterprise-level groups grant no default access; organization-level groups grant default access that owners can restrict. Getting this wrong blocks legitimate jobs or over-shares runners. Source: https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/manage-larger-runners.

Know your group type and its default

Enterprise-level group: repositories have NO default access; owners must grant it (per GitHub docs).
Organization-level group: repositories have default access; owners can restrict it (per GitHub docs).
Match the default to your intent before adding exceptions.

Set repository access on the group

Open Settings, Actions, Runner groups, select the group, and under Repository access choose All repositories or Selected repositories, then add the repositories that need it. Source: https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/manage-larger-runners.

Verify with a test job

Run a minimal workflow in the affected repository that targets the runner by label. If it now picks up, access is correct; if it still queues, re-check the label match too.

.github/workflows/probe.yml

jobs:
  probe:
    runs-on:
      labels: ubuntu-24.04-16core
    steps:
      - run: echo "picked up on a larger runner"

Reducing group-management overhead

Managing enterprise and organization group access across many repositories is real ongoing work. Latchkey managed runners avoid runner-group configuration entirely; access is not gated by group membership, so this class of permission triage does not apply.