Triage the open issue backlog: backfill v1/v2 labels, close legacy, board the rest

[cliffhall]

The PR backlog was triaged and closed (#1819 — 120 closed under closed-v1-deprecated, 8 of those additionally closed-v1-security-declined, 5 retained for a final 1.0.5). The issue backlog has not had the same pass.

The state

• 189 open issues, of which 154 carry neither v1 nor v2 — including most recent ones.
• An unlabeled issue belongs to no version line and appears in no version-filtered query, so it is effectively invisible. AGENTS.md now requires exactly one of v1/v2 at creation, defaulting to v2 — but that only binds new issues.

The work

1. Backfill the version label on all 154 unlabeled issues. Cheap heuristics first, then hand-check the remainder:

   • Already on the V2 board → v2 by definition.
   • Opened after the v2/main cutover → almost certainly v2.
   • Everything older: v1

2. Close the legacy ones. Many describe v1 behavior that no longer exists — v1 is deprecated and takes security fixes only, so a v1-only functional bug is closed, not fixed. Reuse the deprecation note from below under "Deprecation close".

3. Every remaining open issue, once labeled, will be manually reviewed by a maintainer for addition to the board or closing.

---

Labels to use when closing

The PR pass created these two; reuse them so issues and PRs are queryable together. Note the descriptions say "Closed unmerged" — reword them if that reads oddly for issues.

Label	Colour	Use for
closed-v1-deprecated	#B60205	Every issue closed in this pass.
closed-v1-security-declined	#5319E7	The subset deliberately declined on security grounds. Applied in addition to closed-v1-deprecated, so the deprecated label stays a complete census of the sweep.

When does an issue get closed-v1-security-declined?

Most of this backlog won't. The label exists because several PRs shipped code that weakened a control; an issue that merely describes a problem proposes nothing to decline. Apply it only when all three hold:

1. The issue asks for a change — a feature, a default, a new option — rather than reporting that something is broken.
2. Granting it as asked would remove or widen one of the layered controls. In practice that means: making proxy auth optional or off-by-default; binding to all interfaces; disabling or skipping origin validation; widening the MCP Apps sandbox allowlist; sending credentials/cookies to arbitrary targets; letting the client steer the backend's upstream connections; dropping the RFC 8707 resource (audience) parameter; or keeping OAuth client secrets that are currently cleared.
3. The underlying need can't be met without that weakening. If it can, don't decline it — say so and point the requester at the safe path, or carry it to v2.

Never use it for a vulnerability report. An issue reporting a security flaw is not a declined proposal — it goes through GitHub Security Advisories, and v1 still takes security fixes. Closing such an issue with either label would be wrong on both counts.

Everything else — bug reports, usability complaints, requests we simply won't build — gets note A and closed-v1-deprecated alone.

Closing notes

These are the notes used on the 120 PRs (#1819), adapted for issues — Adjust further as needed; the substance to preserve is: thank them, state the policy, make clear it isn't a quality judgment, and invite a v2 issue if the problem persists.

A. Deprecation close — the default, for the great majority

Closing: v1 is deprecated.

Thank you for reporting this, and apologies for the long wait for a response.

v1 will receive security fixes only — This issue describes a functionality, compatibility, or usability problem rather than a vulnerability, so it is being closed against v1. This is not a judgment on whether the problem is real — it's a consequence of the v1 line being frozen. This is happening as part of #1872.

If this still happens in v2, we'd genuinely like to know. v2 is a complete rewrite — three clients over a shared core — so many v1 behaviours no longer exist in the same form. Please open a fresh issue against v2 with steps to reproduce, and we'll look at it. Note that we accept external contributions as issues rather than pull requests; maintainers handle design and implementation through a prompt-driven workflow. See CONTRIBUTING.md.

Thanks for taking the time to report it.

B. Security-decline close — only when the three criteria above are met

Closing: v1 is deprecated, and this one we'd decline on its own terms.

Thank you for raising this, and apologies for the long wait for a response.

v1 is deprecated and takes security fixes only, so this is being closed against v1 either way — but it's worth saying why we wouldn't build it in v2 as described, rather than leaving that implied.

The Inspector's backend spawns local processes and proxies outbound requests on the developer's behalf. It defends that in layers: session-token auth, origin validation, loopback-only binding, and an SSRF block-list on the proxy. What's requested here would remove or widen one of those layers, and we treat that as a net loss even when the problem it solves is real — which it may well be here. That's a judgment about the mechanism, not about you or the use case.

As part of #1872, we're labeling this closed-v1-security-declined so the decision is queryable and doesn't get re-proposed later without the context.

If the underlying need is real, we'd still like to solve it. Please open an issue against v2 describing the problem you hit — the workflow you couldn't complete — rather than the specific change you'd make, and we'll look for a way there that keeps those controls intact. See CONTRIBUTING.md.

Two things the PR pass learned

1. Throttle the close loop (~3–4s between issues). The PR pass ran 120 closes without hitting a rate limit at that pace.
2. Editing a close comment to add #1819 back-fills the cross-reference on that issue's timeline, so every closed item shows up in its "linked" list. Verified during the PR pass — worth doing here too so Triage the open issue backlog: backfill v1/v2 labels, close legacy, board the rest #1872's sweep is auditable from one place. But post the reference in the original comment rather than editing 150 of them afterwards.