Plan PRs can auto-close their ticket's issue via closing keywords in PR body prose

[suleimansh]

Found live during the #1327 10-wide fan-out verification (2026-08-17).

What happened: the pinned plan agent for 2026-07-25_queue-button-doesnt-work wrote in its PR body (#1560): "…then comment on and close #1164." GitHub parses close #1164 in a PR body as a closing keyword, so when the plan PR merged, GitHub auto-closed #1164 even though only the plan — which explicitly says the implementation remains — had landed. Knock-on damage: the next tickets/ sync (#1566) saw the closed issue and removed the ticket and its fresh plan from the repo; both had to be restored by hand and #1164 reopened.

Why it will recur: plans naturally end with "…then close #NNNN" as their final step. Any such phrase in a PR body is a live trigger; the failure needs no one to do anything wrong at review time, because the body reads perfectly sensibly to a human.

Fix directions (either or both):

1. Prompt-side: the pinned plan prompt (and the detached-session closure instruction) tells agents to avoid GitHub closing-keyword phrases (close/fixes/resolves #N) in PR titles/bodies unless the PR genuinely completes the issue — e.g. write "then close issue 1164 (manually)" or "then the issue can be closed".
2. Framework-side: the PR-opening path for plan-only runs could lint the generated body and rewrite #N closing phrases into non-keyword forms (e.g. wrapping the issue ref in backticks defeats the parser).

Direction 1 is prompt surface (maintainer's call per convention); direction 2 is mechanical and testable.

[suleimansh]

🤖 agent comment

Investigated before implementing. Neither fix direction in the OP works as written — one would break correct behavior, and the other cannot reach the path that actually failed.

Direction 2 (lint closing keywords out of PR bodies) would break more than it fixes. Closing keywords in PR bodies are normally correct: 8 of the last 40 PRs carry one, and nearly all are intended — #1604 "Fix #1599", #1603 "(fix #1601)", #1595 "(fix #1582)". A blanket lint would stop those from closing their issues, which is the same bug pointing the other way.

The bad case isn't syntactic. It is a PR that does not complete the issue carrying a phrase that says it does — a semantic judgment no linter can make from the text.

The specific route that failed here is already half-closed. #1560 was a plan PR, and plans no longer travel by PR: the pinned plan prompt now says the plan is "a data write, not a PR" (auto-pm.ts:305), since #1582 moved data onto tf-data.

But the underlying bug is live, through a path neither direction covers. The framework composes PR bodies in agentPrBody (agent-handoff.ts:766) — the intent plus a session line — and that path is sanitizable. #1560 did not come from it: its body was agent-authored prose ending in Claude Code's own _Generated by [Claude Code](…)_ footer, so the agent ran gh pr create itself.

Nothing in the prompts asked it to. hands_off.md:9 is the only prompt that mentions opening a pull request, and it applies only to the web location (isHandsOff is location === 'web'), while #1560 came from the local 10-wide fan-out. The agent opened its own PR, with its own body, outside the framework's handoff path — where a framework-side lint can never see it.

Worth separating out, because it is the bigger finding: agents open their own PRs outside the handoff path at all. That also bypasses the framework's PR title convention — the ticket's (fix #N) from #1334 — and the handoff path is what records the PR number on the agent. The closing-keyword incident is one symptom of that, not the whole problem.

What would actually work:

1. Prompt-side, the only thing that reaches agent-authored bodies: do not write close/fixes/resolves #N unless the PR completes the issue; for a plan or an analysis, write "then #N can be closed". Prompt surface, so it is @brillout's call — happy to draft it.
2. A narrow framework guard: strip closing keywords from agentPrBody only for runs whose deliverable is not the implementation (plan/analysis presets), never globally, so the The dashboard shows what the daemon finds wrong with a project; first emitter: the data-branch sync (fix #1599, towards #1500) #1604 case keeps working.
3. Separately, decide whether agents should open their own PRs at all, given the framework already does it on the handoff path.

Holding implementation until there is a call on 1 and 3.

[brillout]

As always, I'd frame it as a capability: an agent can call a TF function (e.g. tf_open_pr) to trigger the PR creation (kinda like how agents call the $ gh CLI). But the agent can decide to not call the TF function (for whatever reason) and do it itself instead. We avoid limiting agents — we enable agents instead.