[Triage] Bug auto-closed as duplicate of an issue that was then auto-closed as NOT_PLANNED; both locked, leaving no open tracker

Summary

A reproducible bug about context accounting currently has no open issue anyone can contribute to, because automated triage closed the report as a duplicate of an issue that was itself then auto-closed for inactivity — and both were subsequently locked.

This is a report about the triage path, not about the underlying bug. The technical report is filed separately as #85439.

The chain

| Date | Event |
|---|---|
| 2026-03-03 | #30480 filed — [BUG] disabled system tools still consume the context. Real discussion follows: 6 comments, 3 reactions, two workarounds proposed, one correctly rejected as off-topic by the reporter. |
| 2026-03-25 | #38680 filed — Disabled skills still consume context tokens. Clear repro steps, expected vs. actual. |
| 2026-03-29 | Bot auto-closes #38680 as DUPLICATE of #30480. Four days after filing. No human comment on the issue at any point. |
| 2026-04-06 | Bot auto-closes #30480 — the duplicate target — as NOT_PLANNED: "Closing for now — inactive for too long." |
| 2026-04-14 | Bot locks #30480. #38680 is also locked, active_lock_reason: resolved. |

Net result: a bug report was redirected to a second issue, that second issue was then abandoned for inactivity, and both were locked so nobody can add evidence to either. The lock message advises "please file a new issue and reference this one" — which routes the next reporter straight back into the duplicate detector.

This is not a one-off

Every issue in this problem area is closed except two:

| Issue | State | Title |
|---|---|---|
| #14882 | OPEN | Skills consume full token count at startup instead of progressive disclosure |
| #13344 | OPEN | [BUG] Plugin enable/disable ignored - all skills loaded regardless of settings |
| #38680 | CLOSED / DUPLICATE | Disabled skills still consume context tokens |
| #30480 | CLOSED / NOT_PLANNED | [BUG] disabled system tools still consume the context |
| #30304 | CLOSED / NOT_PLANNED | settingSources: [] still loads user-level MCP servers and skills |
| #29711 | CLOSED / NOT_PLANNED | Feature Request: Deferred Loading for Skills (SkillSearch, like ToolSearch) |
| #35051 | CLOSED / NOT_PLANNED | Skills system-reminder injection wastes massive tokens for power users |
| #42650 | CLOSED / NOT_PLANNED | Feature: Deferred skill discovery to reduce context window overhead |
| #43816 | CLOSED / NOT_PLANNED | Feature Request: SkillSearch — lazy-load skill descriptions like Tool Search |

Four independent proposals for the same fix, all NOT_PLANNED. Users on #14882 have posted substantive measurements — one with 246 skills estimating 1.2–2M wasted tokens in a single session, another measuring ~10k tokens of skill descriptions at startup across 148 skills, a third running a controlled experiment with a purpose-built test skill. That evidence has nowhere to land, because the issues designed to hold it keep getting closed.

Why the automation misfires here

1. Duplicate detection doesn't check whether the target is alive. Closing A as a duplicate of B is only sound if B remains open and tracked. #38680 → #30480 pointed at an issue that died nine days later. Nothing re-opened #38680 or re-pointed it.

1. Inactivity closure treats discussion as the signal. #30480 had comments, reactions, and an unresolved technical question. "Inactive for too long" measured time since the last comment, not whether the bug was fixed. Nobody from the team had responded, so there was nothing for the reporter to respond to — the silence that triggered closure was the maintainer side's.

1. Locking removes the escalation path. Once locked, a user who reproduces the bug cannot comment with new evidence. The only remaining action is filing a fresh issue, which re-enters the same duplicate detector. That is a loop, not a funnel.

1. NOT_PLANNED is ambiguous. Applied by a bot for inactivity, it is indistinguishable from a deliberate product decision. Readers reasonably conclude the request was declined on the merits when it was never evaluated.

Suggested changes

None of these require judging the underlying bug:

• Don't close as duplicate against a closed target. If B is closed, leave A open, or re-open A automatically when its duplicate target closes as NOT_PLANNED.
• Distinguish bot-inactivity closures from product decisions. A separate stale reason, or a label, so NOT_PLANNED retains meaning.
• Don't auto-lock issues that received no maintainer response. Locking is reasonable for resolved issues; on untriaged ones it destroys the only channel for new evidence.
• Exempt issues with reactions or multiple distinct commenters from inactivity closure — those are the signals that a report has corroboration.
• When several issues are closed as duplicates of one another, ensure one survives as the canonical tracker.

Why I'm filing this

I hit the underlying bug this week, reproduced it cleanly across three configurations, and went to add my data to the existing report — and found every relevant issue closed and locked. I filed #85439 rather than commenting, because commenting was not possible. The next person to reproduce this will do the same, and their issue will likely be closed as a duplicate of mine.

The bug itself may well be low priority; that is a legitimate call. But it should be a call someone makes, and right now the automation is making it by default and hiding the evidence that would inform it.

Related

• #85439 — the technical report this triage path blocked
• #14882, #13344 — the two surviving open issues
• #38680, #30480, #30304, #29711, #35051, #42650, #43816 — closed