/feedback returns 403 — cannot submit bug reports for 3 days

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/28030
2. https://github.com/anthropics/claude-code/issues/10905
3. https://github.com/anthropics/claude-code/issues/48771

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

Hit the same 403 today and traced the cause. Posting findings in case it helps prioritize a fix and saves the next person the debugging time.

One likely root cause: long-lived env-var tokens are inference-scoped only.

If you're authenticated via CLAUDE_CODE_OAUTH_TOKEN (or claude setup-token), the leaked TS source at https://github.com/yasasbanukaofficial/claude-code documents that these tokens are deliberately limited to the user:inference scope. 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, but the client-side handler at Feedback.tsx:575-583 only recognizes the ZDR-org variant of the message and silently fails for everything else, hence the opaque "couldn't send feedback / 403" with no explanation.

Quick test for whoever can repro: unset CLAUDE_CODE_OAUTH_TOKEN; claude /login to get a real interactive OAuth token (which carries user:profile), then retry /feedback. If it works, it's the scope issue.

Two small fixes that would close this class of bug:

1. Pre-flight gate. Before posting in Feedback.tsx:518, check hasProfileScope() and short-circuit with an actionable message. The bridge code already does exactly this 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."

Same pattern, copy-paste with a feedback-flavored message. The bridge fix was prompted by #33105; feedback is missing the equivalent.

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 essentially "catch one specific 403, drop everything else on the floor."

---

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 this: pattern-matching the minified bundle to find the exact symbols 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. I mention this without coercion: bugs would land with precise root causes far more often if the readable source were officially available, and it would save Anthropic engineers a lot of triage cycles compared to forcing every reporter to either guess or RE the bundle.

This continues to be a problem, the issue is not stale.

Experiencing this issues now. v2.1.185

How is this still broken?

Worth adding a code-level detail: the 403 is handled in two places.
A specific handler checks for error.type === "permission_error"
plus "Custom data retention settings" in the message and reports
the ZDR case properly. Everything else falls through to a generic
401 / 403 / 429 branch that discards the response body and shows
only the status code. So a transient 403 is indistinguishable from a
policy refusal, and the only way to see the server's reason is to
re-run under claude --debug api. Surfacing error.message when
the body has one, as the ZDR branch already does, would make these
reports self-diagnosing.