Live Share SDK 2.0.0

[huntj88]

No description provided.

In general, the fix is to add a permissions: block that explicitly scopes the GITHUB_TOKEN to the least privileges the workflow needs. For this workflow, it only checks out code and installs/builds dependencies, so contents: read is sufficient.

The best minimal fix without changing existing behavior is to add a workflow-level permissions: block right after the name: (or before jobs:). This will apply to all jobs that do not define their own permissions. We will set:

permissions:
    contents: read

This ensures that the GITHUB_TOKEN can read repository contents (needed for actions/checkout if the repo is private) but cannot write. No additional methods, imports, or definitions are required; it is purely a YAML configuration change in .github/workflows/live-share-build-samples.yaml.

Concretely, edit .github/workflows/live-share-build-samples.yaml to insert a permissions: section between line 2 and line 3 (between the workflow name and the on: block).

In general, the fix is to explicitly declare a permissions block for the workflow or for the specific job, setting least‑privilege scopes instead of relying on inherited defaults. For a formatting‑check workflow that only needs to read the repository contents, contents: read is an appropriate minimal setting.

For this concrete file, the simplest and least intrusive fix is to add a root‑level permissions: block (applies to all jobs) immediately after the name: or on: section, specifying only contents: read. This documents the intent and ensures the GITHUB_TOKEN cannot write to the repository even if the org/repo default is broader. No additional libraries, imports, or functional changes are required because permissions configuration is purely declarative in the workflow YAML.

Concretely: in .github/workflows/live-share-formatting.yaml, insert:

permissions:
    contents: read

right after the on: block (or right after name:); keeping existing indentation consistent with the file. No other edits are needed.

Generally, this issue is fixed by adding an explicit permissions block to the workflow or specific job(s), limiting GITHUB_TOKEN to the minimal required scopes (typically contents: read for a pure CI job). This prevents the workflow from inheriting broader default permissions from the repository or organization.

For this workflow, the best fix without changing functionality is to add a permissions block at the workflow root (top-level, alongside name and on). The job only checks out code and runs Node/npm commands; it does not need to write to the repository or other resources via the GitHub API. Therefore, contents: read is sufficient and matches the minimal starting point suggested by CodeQL. Concretely, in .github/workflows/live-share-test-packages.yaml, insert:

permissions:
    contents: read

between the existing on: block and the jobs: block (i.e., after line 8 and before line 10). No additional imports, methods, or definitions are needed since this is just a YAML configuration change.

In general, the fix is to add an explicit permissions: block declaring the minimal scopes needed by this workflow. For a test-only workflow that just checks out code and runs Node/npm/pnpm commands, contents: read is typically sufficient. Declaring this at the workflow root will apply to all jobs that do not override permissions.

The single best fix here, without changing functionality, is to add a root-level permissions: block right after the name: (before on:) in .github/workflows/live-share-test-usage.yaml:

name: Test Usage of Live Share SDK packages in different JS environments
permissions:
    contents: read

This restricts the GITHUB_TOKEN to read-only access to repository contents, which supports actions/checkout@v4 and normal test execution, while avoiding unnecessary write powers. No additional imports, methods, or other definitions are needed; it is purely a YAML configuration change in this workflow file.