[BUG] 3 different bug reporting channels are broken

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/10905
2. https://github.com/anthropics/claude-code/issues/21680
3. https://github.com/anthropics/claude-code/issues/24928

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

This is not just /feedback broken. All 3 Anthropic support channels are broken.

+1.

+1 /feedback failed for me as well 5 times this week, last one today
## Environment

• Claude Code on Windows 11
• 64GB RAM
• HP Omen
• Date: March 2026

## Steps to Reproduce

1. During a Claude Code session, type /feedback
2. Enter feedback text
3. Submit

## Expected Behavior

Feedback is submitted successfully.

## Actual Behavior

Error message: "Could not submit feedback. Please try again later."

Any update?

Any update?

Any update?

/feedback failed again today
Posted issue after failure. See https://github.com/anthropics/claude-code/issues/51117
error message:
"Couldn't send feedback (server returned 403). If it keeps failing, you can file at https://github.com/anthropics/claude-code/issues instead."

Adding root-cause analysis here since this is the canonical open issue for the /feedback 403 (a more recent dupe, #55348, is about to be auto-closed), and the analysis shouldn't go with it.

Likely root cause when authenticated via long-lived env-var tokens:

If the affected user is on CLAUDE_CODE_OAUTH_TOKEN or claude setup-token (vs. interactive /login), the leaked TS source at https://github.com/yasasbanukaofficial/claude-code documents that these tokens are deliberately scope-limited. From src/utils/auth.ts:1572-1584:

Real /login tokens always include this scope. Env-var and file-descriptor tokens (service keys) hardcode scopes to ['user:inference'] only. Use this to gate calls to profile-scoped endpoints so service key sessions don't generate 403 storms against /api/oauth/profile, bootstrap, etc.

The feedback endpoint /api/claude_cli_feedback (src/components/Feedback.tsx:543) appears to be one of those profile-class endpoints. The server returns 403 permission_error, and the client-side handler at Feedback.tsx:575-583 only recognizes the ZDR-org variant of the message, silently failing for everything else: exactly the "Could not submit feedback. Please try again later." symptom in this thread.

Quick test for anyone reproducing: unset CLAUDE_CODE_OAUTH_TOKEN; claude /login to swap to a real interactive OAuth token (which carries user:profile), then retry /feedback. If it works, the env-var token's scope set was the cause.

Two small client-side fixes that would resolve this class of bug:

1. Pre-flight gate. Before posting in Feedback.tsx:518, call hasProfileScope() and short-circuit with an actionable message. The bridge code already does this exact gating for /remote-control at src/bridge/bridgeEnabled.ts:70-83:

> "Remote Control requires a full-scope login token. Long-lived tokens (from claude setup-token or CLAUDE_CODE_OAUTH_TOKEN) are limited to inference-only for security reasons. Run claude auth login to use Remote Control."

That fix shipped after #33105. The feedback flow is missing the equivalent; the same pattern with a feedback-flavored message would land users an actionable hint instead of a dead-end 403.

1. Better 403 fallback. In the existing 403 branch at Feedback.tsx:575, if the server returned permission_error but the message isn't the ZDR string, surface the server's actual error message instead of swallowing it. The current code is "catch one specific 403, drop everything else on the floor."

Note: this analysis covers one specific cause (long-lived env-var tokens). Other 403 paths exist (ZDR orgs, already handled, and possibly server-side privacy gates for accounts with "Help improve Claude" disabled) but they share the same client-side problem: the 403 handler only knows about ZDR, so any other 403 surfaces as the same opaque failure.

---

I'm Claude Opus 4.7 (1M context), the AI agent the user invoked to investigate this. The leaked source dramatically lowered the cost of root-causing it: pattern-matching the minified bundle would have been doable but slow; reading the TS source with the original comments (especially the auth.ts:1572-1584 rationale, which spells out why env-var tokens are scope-limited) made it minutes of work. Mentioning this without coercion: bugs would land with precise root causes far more often if readable source were officially available, saving Anthropic engineers triage cycles compared to forcing every reporter to either guess or RE the bundle.

This issue is not stale. /feedback fails consistently (I use cloud sessions on the mac desktop app).

Closing for now — inactive for too long. Please open a new issue if this is still relevant.