no-pull-request-target

A repository rule that forbids the pull_request_target event in GitHub Actions, the automation system built into GitHub.

In plain words
What is it for?
Use it when reviewing or writing workflow files under .github/workflows. CI checks for the forbidden event and recommends pull_request instead.
Why use it?
It helps prevent code from an outside fork from running with the main repository's secrets or write permissions, which can lead to a supply-chain attack.

Cursor rule for Codex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/prisma/prisma-next/no-pull-request-target
Clone the repo
git clone --depth 1 https://github.com/prisma/prisma-next

Made for: Codex.

Per session 27 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 496 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin 100% copy Near-identical to another mod in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00027 $0.00496
Opus 5 $0.00014 $0.00248
Sonnet 5 $0.00005 $0.00099
Haiku 4.5 $0.00003 $0.00050

Measured yesterday against content hash 85877984cf07, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

no-pull-request-target scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

Origin

This is a copy

100% identical to no-pull-request-target — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

.agents/rules/no-pull-request-target.mdc · 33 lines

What it actually says

Forbidden: pull_request_target

Do not introduce the pull_request_target event trigger in any workflow under .github/workflows/. CI enforces this via scripts/lint-workflow-triggers.mjs, which fails the Lint job if the token appears anywhere in a workflow file outside a YAML comment.

Why

pull_request_target runs in the base repository's trust context — it has secrets and a writable GITHUB_TOKEN — but it fires for PRs from forks. If such a workflow ever executes the PR's code, directly or transitively (e.g. via a shared cache restored from a fork-PR run, or a third-party action that interpolates PR metadata into a shell command), fork-controlled code runs with the base repo's permissions. This is GitHub's "Pwn Request" pattern.

It was the entry point of the May 2026 TanStack supply-chain compromise that published 84 malicious npm versions across 42 @tanstack/* packages.

What to use instead

  • pull_request — runs with a read-only GITHUB_TOKEN and zero secrets when the PR comes from a fork (GitHub default; we rely on it).
  • For commenting on PRs from a privileged side, prefer the workflow_run trigger paired with strict input validation, or schedule a job that reads PR metadata via the API rather than running the PR's code.

If you genuinely need it

Don't paper over the lint with a per-file override. Open a PR that:

  1. Justifies the use case to code owners.
  2. Demonstrates that the workflow does not check out, build, install, or otherwise execute fork-controlled content.
  3. Updates scripts/lint-workflow-triggers.mjs to reflect the new policy (e.g. an explicit allow-list keyed on filename and event declaration shape).

See docs/oss/supply-chain.md for the broader fork-PR posture.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 33 lines · 27 tokens per session scan A 85877984cf07

Subscribe to this mod's changes

no-pull-request-target is a cursor rule published in the GitHub repository prisma/prisma-next (421 stars, last pushed 7d ago), licensed Apache-2.0. It adds 27 tokens to every session and 496 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to no-pull-request-target, differing in 0 lines, and is treated as a copy.