[Bug] /feedback attaches all session errors to unrelated filings, creating triage noise

Resolved 💬 2 comments Opened Apr 12, 2026 by jordandm Closed May 23, 2026

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

  • Name: Jordan Dea-Mattson
  • GitHub: @jordandm (the-agency-ai), @jordan-of (OrdinaryFolk)
  • Email: jordandm@users.noreply.github.com, jordan-of@users.noreply.github.com
  • Framework: https://github.com/the-agency-ai/the-agency
  • Claude Code version: 2.1.101

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.

View original on GitHub ↗

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