Your AI Agent's Patch Is Fine. The Repo Won't Let You File It.

The first hard failure in an agent-written contribution is not a failing test. It's a closed door, and it is documented before you write a line of code. Two different walls show up in large repos, and conflating them costs days. Wall one: you cannot open the PR python-jsonschema/jsonschema has issue #1590 open since 2026-10-16: draft 2019-09 unevaluatedItems crashes when items is a boolean schema. Five comments, no patch. The route to submitting one is blocked at the door, because the repo restricts pull request creation to collaborators. Check that before writing anything: gh api 'repos/python-jsonschema/jsonschema/pulls?state=all&per_page=100' \ --jq '[.[] | select(.head.repo.fork)] | .[0] | {number, created_at}' That returns #1572, created 2026-09-01 — the most recent cross-fork PR in the repo, 67 days ago. The thirteen newest PRs after it are dependabot and pre-commit-ci. If that timestamp is old while the issue counter keeps climbing, your patch is not the bottleneck. Wall two: you may open it, but not like that pallets/click issue #3362 is the same shape of small, well-specified bug: HelpFormatter.write_usage splits a long option at the hyphen when the usage string wraps. The repro lists --enable-verbose-logging, --output-file-path, --max-retry-count and friends. Opened 2026-04-21, still open. The reply a maintainer left on that issue was one sentence: "It is not acceptable to let LLM agents open issues/PRs autonomously", pointing at the project's LLM policy. That policy is not a code review standard. It applies to "code, documentation, tests, PR descriptions, comments, reviews, answers, and all other interactions". Contributions that look generated, or attempts to hide that, get closed and the account is likely blocked. For new contributors the rule is stricter than disclosure: don't use the tools at all. That is what makes the policy a preflight item rather than a postmortem. There is nothing to fix in review — the submission itself is the violation. The useful distinction is autonomy, not AI Python-Markdown's contributing docs are the clearest text I've found, because they permit AI assistance and still close the hole agents fall into. Three lines: "The use of an AI agent to submit a pull request, issue, or comment autonomously is not permitted." Disclosures must name "the specific tools used and what content was generated" — code, docs, comments, commit messages, explanations. "Copying and pasting replies to / from a generative AI tool does not count as engaging with the reviewer." One enforcement detail deserves a second read: if the issue or PR template is ignored or deleted, it is assumed an agent submitted autonomously and the item may be closed immediately. The template is the tripwire. So the rule is not "no model touched this diff". It is: a human is accountable, names the tools, and answers review in their own words. A patch can be almost entirely machine-written and still legal there — the account just has to be able to explain every change on request and reply to the reviewer itself. Run this before generating the patch Three checks, a few seconds total: # 1. policy grep -riE 'generative ai|llm|ai agent|autonomous' \ CONTRIBUTING* docs/contributing* README* .github/ 2>/dev/null # 2. entry point: cross-fork PR recency gh api "repos/$OWNER/$REPO/pulls?state=all&per_page=100" \ --jq '[.[] | select(.head.repo.fork)] | .[0] | .created_at' # 3. queue: does anything merge at all? gh api "repos/$OWNER/$REPO/pulls?state=closed&per_page=20" \ --jq '[.[] | select(.merged_at != null)] | .[0].merged_at' If the first grep hits a line about autonomy, or about not using the tools at all, the agent stops before writing. If the second is months stale, the patch is probably unsendable. If the third is months stale, submitting is a coin flip on maintainer time, which is a different problem from the one you think you are solving. Wire each one to a non-zero exit, not to a warning in a log nobody reads. The failure you are avoiding is an afternoon spent on a diff that gets closed with a link to a policy. The honest part Policy is not the only wall. On that same Click issue a human opened PR #3902 on 2026-11-02 against stable, and it is still open and unmerged. A permitted contributor with a permitted workflow still waits in the same queue. Two of these three gates have nothing to do with how good the code is, which is exactly why checking them first is cheaper than discovering them last.