github-shared.yml@v0.16.2 fails with startup_failure when called cross-repository

[ineedjet]

Context

Follow-up to #175/#176 (labels check 403, fixed in v0.16.2). After bumping dupmachine/flightdeck-config's github.yml from github-shared.yml@v0.16.1 to @v0.16.2, every single run fails with startup_failure - a workflow-parse/dispatch-time failure with zero jobs created. This is distinct from the earlier 403: no check-run is posted at all (confirmed via gh api repos/{repo}/commits/{sha}/check-runs - the run simply doesn't appear), so it's invisible in the PR checks UI, not just failing loudly.

Reproduction

Caller (dupmachine/flightdeck-config/.github/workflows/github.yml):

name: GitHub
on:
  push:
    branches: ["main"]
  pull_request:
jobs:
  github-config-check:
    uses: rubykatzen/baseline/.github/workflows/github-shared.yml@v0.16.2
    with:
      skip: '["autoMergeAllowed"]'

Result: startup_failure, reproduced across 7 consecutive attempts including fresh git commit --allow-empty dispatches (not just reruns of a stale attempt) spanning several minutes, ruling out propagation delay after the tag was cut. Example run: https://github.com/dupmachine/flightdeck-config/actions/runs/32830117795

Content variations tried, all fail identically:

• with with: skip: [...]
• without any with: block at all
• different skip array contents

What changed between v0.16.1 (works) and v0.16.2 (fails)

The only diff in github-shared.yml itself is the job's permissions: block gaining issues: read (the #176 fix):

  github-config-check:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: read   # <- new in v0.16.2

Isolating the cause

An isolated test workflow directly in dupmachine/flightdeck-config (not a reusable workflow call - just a plain job in that repo) with the exact same permission set succeeds fine:

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: read
    steps:
      - run: echo ok

So issues: read isn't blocked in this repo/org in general - the failure seems specific to a reusable workflow's job requesting issues: read (alongside contents: read) when called cross-repository. embedder-shared.yml's job (permissions: contents: read only) and lint-shared.yml's job (no permissions block) both work fine cross-repo at v0.16.2 - github-shared.yml is the only shared workflow with two explicit permission keys, and the only one failing.

Current workaround

Pinned github.yml back to github-shared.yml@v0.16.1 (with skip: '["labels", "autoMergeAllowed"]', since v0.16.1 still has the original #175 labels bug). Everything else in that repo is on v0.16.2 fine.

🤖 Generated with Claude Code

[ineedjet]

Resolved on the consumer side, not a baseline bug: the calling job needs its own explicit permissions: block matching what the reusable workflow's job requests, in addition to (not instead of) the reusable workflow's own declaration - for cross-repository uses: calls, GitHub apparently requires this explicit grant on the caller's job or the whole call fails at dispatch time (startup_failure, no check-run posted at all).

Fix in dupmachine/flightdeck-config#50:

jobs:
  github-config-check:
    permissions:
      contents: read
      issues: read
    uses: rubykatzen/baseline/.github/workflows/github-shared.yml@v0.16.2
    with:
      skip: '["autoMergeAllowed"]'

Might be worth a one-line note in this repo's own README/example for github.yml callers, since embedder-shared.yml/lint-shared.yml callers didn't need this (their reusable jobs only ever requested a single permission or none), so it wasn't obvious until a second scope got added.

🤖 Generated with Claude Code