ci: allow isolated fork recipe checkout

[artiehinz]

Summary

Allows the recipe security scanner to read recipe files from fork PRs with actions/checkout@v7.

The workflow already separates trusted scanner code from untrusted recipe data. This change explicitly opts into the isolated recipe checkout and disables credential persistence. Without it, checkout stops before the scanner runs on every fork submission.

Validation

• YAML parse passed
• Workflow diff contains four configuration lines only
• Failure reproduced on docs: add reliability sidecar recipe #10780: checkout refused the fork before scanning

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: aa44e4d349

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Do not opt fork recipes into privileged checkout

For fork PRs that touch recipe YAMLs, this opt-out makes a pull_request_target job check out attacker-controlled recipe data and then the later scan step runs Goose over that data in a container that has OPENAI_API_KEY and the training-data secrets plus shell/network-capable developer tooling. Because recipes are themselves prompt/instruction documents, a fork author can put prompt-injection or external-download instructions in the recipe and have them processed in the same privileged scanner context; persist-credentials: false only removes git credentials and does not protect those scanner secrets. Keep fork recipe scanning in an unprivileged pull_request context or withhold secrets/network until the recipe is maintainer-approved.

Useful? React with 👍 / 👎.

[artiehinz]

Agreed. Checking attacker-controlled recipe content in this privileged pull_request_target job would expose secrets and network-capable tooling. I am withdrawing this PR rather than bypassing the checkout protection.