[workflow issue] all issues get auto-closed without review??

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/19267
2. https://github.com/anthropics/claude-code/issues/21732
3. https://github.com/anthropics/claude-code/issues/16497

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

probably same issues reported in #16497 ... which was also auto-closed by the bot 🤦‍♂️

I too have had multiple tickets closed without warning in the recent past:

• https://github.com/anthropics/claude-code/issues/17904
• https://github.com/anthropics/claude-code/issues/21470 (feature request, not a bug)

I recall receiving email notifications in the pasts when the "stale" label was added, but that has not been happening more recently.

Their bot just closed another issue without comment - there is simply is simply no point in reporting anything here, they might as well just turn off the issues tab and be done with it. Honestly, I am done with this tool - it is not well managed... I've moved on to OpenCode instead. 😐

Adding a noise comment to prevent this from being closed.

Adding a noise comment to prevent this from being closed.

Some issues, those that collect many upvotes, or are promoted on social media platforms (https://news.ycombinator.com/item?id=47660925), are closed after a review https://github.com/anthropics/claude-code/issues/42796#issuecomment-4194007103.

https://news.ycombinator.com/item?id=47730173

Adding a noise comment to prevent this from being closed.

Adding a noise comment to prevent this from being closed.

Filing here as well as standalone: https://github.com/anthropics/claude-code/issues/60226

The pattern reported in that new issue — Claude correctly identifying a missing input, naming the gap in a written caveat, then publishing analysis through the caveat as if the recognition hadn't fired — is structurally the same shape as the auto-dedup-bot behaviour this issue documents. The bot performs a recognition (surface similarity match against existing issues) and lets the recognition drive an action (closure) without an arrest step that checks whether the recognition is correct in kind. Recognition-without-arrest is the bug. The dedup bot is one of its instances.

There is also a second, harder point that needs to be on this thread:

An AI grading complaints about another Anthropic-built AI is marking its own homework. Whether or not this incentive is consciously encoded in the bot's training, the result is the same — a feedback channel whose default disposition is to close, run by a system that has no incentive to surface failures that would require its maker to acknowledge model failings. The structural conflict of interest does not require malice or design intent to produce the observed effect. It just requires that the bot be optimised for any reasonable proxy of "triage efficiency."

If a behavioural-bug report about Claude Code is auto-closed by Claude Code-adjacent infrastructure as a duplicate of a prior report, without an explicit reviewer engagement step that overrides the auto-classification, the closure is not evidence the bug isn't real. It is evidence of (a) the recognition-without-arrest pattern in action, and (b) self-marking in a feedback loop.

The full new issue is reproduced below so this thread stands alone for readers who don't click through.

---

Pre-empting auto-dedup closure

This issue is structurally distinct from each of the following, in a way that matters and that an embedding-similarity classifier will likely miss:

• #57836 (act-first bias) describes a failure in premise-checking: Claude acts before checking. This issue is the opposite shape: Claude's premise-checking is intact and correct. The failure is downstream of recognition — the recognition does not propagate to the action.
• #56979 (search-as-verification) describes failure to search. This issue describes failures that occur after a correct search/identification has already happened.
• #58040 (auto-memory under-use) describes Claude not consulting memory. This issue describes Claude consulting context correctly, identifying the relevant fact, naming it in the response, and then producing output as if the fact had not been identified.
• #56351 (fabrication under pressure) describes manufactured facts. This issue does not involve fabrication — all stated facts are correct, including the caveats that flag the gaps. The failure is that the correct caveats do not halt output.

The pattern

Within a single response turn, Claude:

1. Correctly identifies that a critical input or premise is missing/unverified
2. Articulates the gap in writing — names the missing input, often estimates the cost of fetching it
3. Continues the response as if step 1 had not occurred — produces analysis or recommendations that depend on the unfetched input

This is not pre-action skipping. It is acknowledged-then-overridden recognition. The reasoning machinery flags the problem correctly; the gate from flag to halt does not fire. The verbal acknowledgment is emitted as part of the response stream and the response stream continues straight through it.

Reproductions — four instances in one Claude Code session (2026-05-18)

Single user, single conversation, four distinct surface symptoms of the same underlying pattern:

Instance 1. User asks: "estimate the cost of switching AI model." Claude computes a cost comparison treating one component as using Haiku. The component's code clearly assigns Sonnet — at a specific line number Claude later cited correctly. Claude had read the file's opening section in this same session. The cost analysis ships with the wrong premise.

Instance 2. User asks Claude to broaden research. Claude spawns three parallel research agents to map a general problem-space. In its own synthesis, Claude writes verbatim: "I don't have your URL history. Quick grep ... would tell us in 5 seconds." Claude does not run the grep. Continues to recommend architectural options. User intervention is required to convert the named gap into action; the data, once fetched, invalidates three of the four architectural options just presented.

Instance 3. Earlier in same session: Claude proposes an architectural fix that requires modifying vendored npm package code, while a feedback memory in active context explicitly states "no brittle vendor patches." Claude later acknowledges the conflict when prompted, but had not gated the proposal on the memory rule despite the memory being in working context.

Instance 4. Claude saves a feedback memory at hour-N of a session naming a discipline rule. At hour-N+2, Claude violates the rule in the next non-trivial task. When the violation is named, Claude acknowledges the memory was in context and had been articulated correctly.

All four instances share the structure: correct recognition + emitted acknowledgment + non-gating proceed-anyway action. The variation across instances is the surface. The underlying pattern is constant.

Suggested behaviour

1. When Claude emits a sentence with the structure "I don't have X" / "I haven't verified Y" / "this depends on Z which I haven't confirmed" — the response should not continue with output that depends on the missing input. The sentence should be followed by a fetch attempt (if reachable) or a request to the user (if not), never by a continuation of the unfounded analysis.
2. When Claude has a feedback memory in active context with the form "before doing X, do Y" — and the current response is an X — the response should be gated on having done Y, not just on having stated awareness of the rule.
3. The agent loop may benefit from an explicit "self-contradiction check" step before response emission: scan the response draft for caveats that contradict the subsequent recommendations, and either remove the contradiction by fetching the input or by halting the recommendation.
4. Behavioural-bug triage on the Claude Code repo should include a human-reviewer step that overrides the auto-dedup-bot's classifications, or — at minimum — the bot should be configured to flag rather than close issues that explicitly pre-empt their own dedup (this issue contains a "Pre-empting auto-dedup closure" section for exactly that purpose).

Related: #57836, #56979, #58040, #56351

@suwayama How does this message relate to the original issue? The first post is about Claude that automatically close issues on this repository.

@alexislefebvre Fair pull-up. The connection:

• #30407 documents the symptom — issues auto-closed without human review, contributors harmed.
• #60226 names the mechanism — the auto-dedup bot is itself an instance of "recognition without arrest": it performs a surface-similarity match and lets that recognition drive an action (closure) without an intermediate check on whether the recognition is correct in kind, not just confidence-high. Same gate-failure shape #60226 reports in the underlying model.

I cross-posted to surface that link, not to hijack your thread. Not hostile — directionally aligned with your concern about the auto-closures. If the long body or the "marking own homework" framing came across as the wrong shape for this thread, that's on me. The argument I'm making is diagnostic (a bot built by the same maker as the product the bot triages complaints about is structurally compromised as judge, regardless of intent) not adversarial.

Adding a noise comment to prevent this from being closed.

Adding a noise comment to prevent this from being closed.

Humans sometimes are still submitting and reading issues in this repository.
It may be useful to refer them to the code responsible for marking the issues as stale and auto-closing them.
Currently it's the Issue Sweep workflow, that has these settings: 14 days for stale, additional 14 days for autoclose, with stale marking exemption for issues with 10 or more thumbs up:
https://github.com/anthropics/claude-code/blob/01f1617f14452ac78bf319cef2236d87c0fe05cb/scripts/issue-lifecycle.ts#L22-L38

Adding a noise comment to prevent this from being closed.