[Bug] /feedback command silently fails; broken for 5+ months while team directs users to it

Resolved 💬 5 comments Opened Apr 11, 2026 by jordandm Closed May 24, 2026

Anthropic Feedback ID: 95fe4771-6780-4be7-9e8e-30d7feea3496 (from /feedback cross-filing on the same date)

---

Bug Description
Communications gap: /feedback has been broken for 5+ months while the Claude Code team publicly directs users to it

Problem

This is a communications / product-trust issue, not (directly) a technical bug report. The technical bug — /feedback silently failing or failing with an unhelpful error
— has been publicly documented since at least November 2025 in #10905 and #12638. Both issues are closed and auto-locked. Multiple users report in the comments that
the bug continues to happen after closure, on recent Claude Code versions, across macOS and other platforms.

Despite the underlying bug being known for this long, members of the Claude Code team have continued to publicly direct users to file via /feedback. Most visibly,
@trq212 posted on X during the Opus 4.5 degradation concerns in February 2026:

▎ "We've received some feedback about a potential degradation of Opus 4.5 specifically in Claude Code. We're taking this seriously: we're going through every line of
▎ code changed and monitoring closely. In the meantime please submit any transcripts with issues through /feedback"

Users following that guidance would hit the broken channel. They would get either a silent SHA drop or a cryptic "Could not submit feedback. Please try again later."
error. They would have no way to verify whether their feedback reached Anthropic. The errors are not even logged to ~/.claude/debug/, so they have no diagnostic trail
to file a GitHub issue with.

Meanwhile, the canonical GitHub issue (#10905) is auto-locked. New users searching before filing see "closed" and assume "fixed." The duplicate detector auto-closes new
reports as duplicates of the closed issue. The feedback loop is structurally shut.

This is the gap I'm reporting: Anthropic is routing users to a broken channel while telling them it's the right channel, and the public tickets documenting the breakage
are closed and locked so the gap is invisible to users who search before filing.

Evidence

The underlying bug has been public for 5+ months

  • #10905 — filed November 2025, CLOSED, auto-locked, 21 comments. Multiple users report continued failure AFTER closure on Claude Code 2.1.56–2.1.58, macOS Tahoe

26.3.1.

  • #12638 — filed 2025-11-28, auto-closed as duplicate. Contains diagnostic data (Plugin source missing trace).
  • #28565 — tracks naming mismatch (/feedback vs /bug) that obstructs search.

Representative quotes from #10905:

▎ "This has been broken for several months. I've never, ever been able to submit."

▎ "Additionally, the feedback submission failure doesn't get logged to the debug files (~/.claude/debug/). Those files capture API calls, tool use, and hook events, but
▎ the /feedback network request and its error are not recorded."

Users can't even include useful diagnostic data when they do manage to file a GitHub issue about the failure.

The team continues to publicly direct users to the broken channel

  • @trq212 February 2026 — during Opus 4.5 degradation concerns, directing concerned users into the broken funnel
  • @bcherny has similarly directed users to feedback channels in launch and update announcements. The pattern is systemic.

My direct experience (today, 2026-04-11)

I build the-agency-ai/the-agency, an AI-augmented development framework on top of Claude Code. I file feedback against Claude Code regularly as part of dogfooding. Over
the past week I accumulated four separate feedback items that I believed filed via /feedback but never produced any visible outcome. Today I discovered they were never
delivered. I'm filing them now via gh issue create directly. Public expression of the frustration: @AgencyGroupAI 2026-04-11.

The only feedback item I can confirm reached Anthropic is one I cross-filed to both /feedback and GitHub on 2026-04-08 — #45017. The GitHub path is the one I can
verify. The /feedback path returned feedback ID 8dd67e96-63ea-4a22-b687-d26a1b2d0add, which I have no way to look up or verify resolved to anything on Anthropic's side.

Why this matters

For users

  • Trust in the feedback system is being burned. Every silent-failure user is an advocate lost and a signal source gone dark.
  • Detailed bug reports are being lost in broken retry paths.
  • The naming mismatch + closed-duplicate cycle hides the known issue from people trying to do the right thing.
  • Affected users end up on Discord, Twitter, Reddit — the "official" path is broken and feedback is fragmenting away from Anthropic.

For Anthropic

  • You are losing a significant chunk of high-signal developer feedback — exactly the feedback you've consistently said you want.
  • Every public "please file via /feedback" post is a moment where your team is unintentionally sending users into a broken funnel.
  • The closed-and-locked pattern creates an information asymm…

Note: Content was truncated.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗