It is a mistake that this was write-all without changing the trigger to be pull_request_target. From Google Gemini:

In GitHub Actions, pull_request and pull_request_target are distinct event triggers for workflows, primarily differing in their security context and the code they execute.
pull_request:

Context:

Runs in the context of the merge commit of the pull request. This means it executes the workflow file as it exists in the pull request's branch, after it's virtually merged with the base branch.

Permissions:

By default, workflows triggered by pull_request events from forks have limited permissions and cannot access secrets from the base repository. This is a security measure to prevent untrusted code from accessing sensitive information.

Use cases:

Ideal for tasks like running tests, linting, or static analysis on the proposed changes within the pull request's scope, where access to repository secrets or write permissions on the base repository are not required.

pull_request_target:

Context:

Runs in the context of the base of the pull request, which is the branch the pull request is targeting (e.g., main). This means it executes the workflow file as it exists in the base branch, not the potentially modified version in the pull request's branch.

Permissions:

Grants workflows access to repository secrets and provides a read/write GITHUB_TOKEN, even for pull requests originating from forks. This makes it more powerful but also carries higher security risks if not handled carefully.

Use cases:

Required for actions that need to interact with protected resources or modify the base repository, such as deploying preview environments, adding labels or comments to pull requests, or performing operations that require elevated permissions.