Fix Copilot setup bootstrap ordering and checkout permissions

[Copilot]

The Copilot Actions job was bootstrapping the environment in the wrong order: pnpm install ran before the repository existed in the agent workspace. The failure also exposed a separate auth issue: the session token presented as GITHUB_TOKEN was invalid, surfacing as the job's authorization error.

• Bootstrap ordering

  • Move repository checkout to the first setup step so all workspace-aware commands run against an actual clone.
  • Initialize Node before package-manager work to keep the bootstrap deterministic.

• Workflow permissions

  • Add explicit contents: read permissions required by actions/checkout in the Copilot setup job.

• Dependency install behavior

  • Keep the setup aligned with the committed lockfile via pnpm install --frozen-lockfile.
  • Continue building workspace packages during setup so the agent lands in a ready-to-use state.

• Workflow operability

  • Add standard triggers for setup-workflow validation so changes to the bootstrap can be exercised directly outside of a Copilot session.

• Auth signal surfaced

  • The authorization failure is not caused by the workflow YAML itself.
  • The exact missing/expired credential surfaced by the run is an invalid GITHUB_TOKEN.

permissions:
  contents: read

steps:
  - uses: actions/checkout@v5
  - uses: actions/setup-node@v4
    with:
      node-version: '20'
      cache: pnpm
  - run: corepack enable && corepack prepare pnpm@9.15.0 --activate
  - run: pnpm install --frozen-lockfile

[L03TJ3]

@copilot what is using or requesting GITHUB_TOKEN.
As far as I know the only token for github connectivity in copilot would be the secret for using the github MCP?

[Copilot]

@copilot what is using or requesting GITHUB_TOKEN.
As far as I know the only token for github connectivity in copilot would be the secret for using the github MCP?

It’s the GitHub Actions job runtime itself, not the MCP secret.

GITHUB_TOKEN is automatically provisioned by GitHub Actions for each job, and actions can read it via the github.token context even if the workflow never declares it explicitly. In this workflow, actions/checkout uses that job token under the hood, and any gh / GitHub API call in the runner would also typically use it.

So the auth failure I surfaced was: the Copilot/Actions job environment had an invalid job-scoped GITHUB_TOKEN. That is separate from the GitHub MCP connectivity secret used by the coding agent tools in this session.