claude-code - 💡(How to fix) Fix [Bug] /feedback attaches all session errors to unrelated filings, creating triage noise [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#46860Fetched 2026-04-12 13:31:10
View on GitHub
Comments
0
Participants
1
Timeline
9
Reactions
0
Author
Participants
Timeline (top)
labeled ×4subscribed ×3mentioned ×2

Error Message

[{"error":"Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Output blocked by content filtering policy"},"request_id":"req_011CZwHyHAGs3JxBGJEgkNGQ"}\n at generate (/$bunfs/root/src/entrypoints/cli.js:11:53430)\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:50:4943)\n at processTicksAndRejections (native:7:39)","timestamp":"2026-04-11T03:43:27.528Z"},{"error":"Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Output blocked by content filterin…

Code Example

[{"error":"Error: 400 {\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"Output blocked by content filtering policy\"},\"request_id\":\"req_011CZwHyHAGs3JxBGJEgkNGQ\"}\n    at generate (/$bunfs/root/src/entrypoints/cli.js:11:53430)\n    at makeRequest (/$bunfs/root/src/entrypoints/cli.js:50:4943)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-11T03:43:27.528Z"},{"error":"Error: 400 {\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"Output blocked by content filterin…
RAW_BUFFERClick to expand / collapse

Bug Description /feedback attaches ALL session errors to EVERY filing — unrelated error noise in triage

Problem

When filing via /feedback, the generated GitHub issue includes an Errors section at the bottom that captures session errors. This is a good feature in principle — session context helps triage.

However, /feedback attaches every error from the entire session to every filing, regardless of whether the errors are related to the feedback being submitted. In a long session where multiple feedback items are filed, the same unrelated errors appear in every single filing.

Steps to reproduce

  1. Start a Claude Code session
  2. During the session, trigger an unrelated error (e.g., a content filter false positive on a Code of Conduct draft — request ID req_011CZwHyHAGs3JxBGJEgkNGQ)
  3. Later in the same session, file multiple /feedback reports about completely different topics (macOS permissions, agent environment variables, session naming, etc.)
  4. Observe: every filing's Errors section includes the same content filter error from step 2, even though the feedback is about macOS permissions or agent naming — topics with zero relationship to the content filter

Observed behavior

Filed 7 feedback items in the same session on 2026-04-11/12. Topics ranged from /feedback reliability to macOS permissions to session identity. Every single filing included the same error block:

[{"error":"Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Output blocked by content filtering policy"},"request_id":"req_011CZwHyHAGs3JxBGJEgkNGQ"}...

This error was from a content filter false positive early in the session while drafting a Code of Conduct. It has nothing to do with macOS permissions (#46859), agent environment variables (#46858), or session identity (#46853) — but it appears in all of them.

Expected behavior

Option A (preferred): Only attach errors related to the filing. Scope the Errors section to errors that occurred near the conversation context being filed — e.g., errors from the last N messages, or errors that the user explicitly references.

Option B: Timestamp-filter recent errors. Only attach errors from the last 5-10 minutes of the session, not the entire session history. Long sessions accumulate hours of unrelated errors.

Option C: Let the user choose. Show the user the errors that will be attached and let them include/exclude before submission. A checkbox list of "include this error? [x] content filter at 03:43 / [ ] timeout at 05:12".

Option D: Separate errors section from the filing body. Attach errors as a collapsed <details> block or a linked artifact, not inline in the issue body. This way triage sees the filing content first and can expand errors on demand.

Why this matters

  • Triage noise: the Anthropic team reading these filings sees the same error block in 7 different issues about 7 different topics. It looks like all 7 issues are caused by the content filter — but only 1 is actually about the content filter (#46546). The other 6 are false associations.
  • Filing credibility: a filing about macOS permissions that ends with a content filter stack trace looks confused. It's not — but the triage reader doesn't know that.
  • The Errors section is already truncated with "Content was truncated" — so the most relevant error details may be cut while irrelevant session errors take up the space budget.

Reporter

Related

  • Filed as part of the 2026-04-11/12 feedback batch (7 items filed, same session, all exhibiting this behavior)
  • Content filter error that leaked across all filings: #46546
  • Also related to /feedback comms gap (#46531) and debug logging (#46538) — all three are about improving the /feedback submission pipeline

Environment Info

  • Platform: darwin
  • Terminal: ghostty
  • Version: 2.1.101
  • Feedback ID: 24fe6d3e-4376-4382-8831-165eedb9c08a

Errors

[{"error":"Error: 400 {\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"Output blocked by content filtering policy\"},\"request_id\":\"req_011CZwHyHAGs3JxBGJEgkNGQ\"}\n    at generate (/$bunfs/root/src/entrypoints/cli.js:11:53430)\n    at makeRequest (/$bunfs/root/src/entrypoints/cli.js:50:4943)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-11T03:43:27.528Z"},{"error":"Error: 400 {\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"Output blocked by content filterin…

Note: Content was truncated.

extent analysis

TL;DR

Filtering or limiting the errors attached to each filing, such as by relevance, timestamp, or user selection, is likely to resolve the issue of unrelated errors being included in every filing.

Guidance

  • Implement a mechanism to scope errors to the conversation context being filed, such as only including errors from the last N messages.
  • Consider adding a timestamp filter to only attach errors from the last 5-10 minutes of the session.
  • Provide an option for the user to choose which errors to include or exclude before submission.
  • Alternatively, separate the errors section from the filing body, such as by using a collapsed <details> block or a linked artifact.

Example

A possible implementation could involve modifying the error collection logic to only include errors that occur within a certain time window or message range of the filing being submitted.

Notes

The ideal solution will depend on the specific requirements and constraints of the /feedback system, including the trade-offs between error relevance, user experience, and triage efficiency.

Recommendation

Apply a workaround, such as implementing a timestamp filter or user-selectable error inclusion, to mitigate the issue until a more comprehensive solution can be developed. This will help reduce triage noise and improve filing credibility.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING