[Feature Request] Log /feedback network requests and errors to ~/.claude/debug/

Anthropic Feedback ID: 229cbbce-6d28-4390-8eb2-aeaecc192b6c (from /feedback cross-filing on the same date)

Companion filing: #46531 — broader /feedback comms gap and reliability issue from the same reporter, same day.

---

Bug Description
Log /feedback network requests and errors to ~/.claude/debug/

Problem

Claude Code logs API calls, tool use, and hook events to ~/.claude/debug/. These log files are the primary diagnostic artifact users include when filing bug reports.

/feedback network requests and their errors are not logged to ~/.claude/debug/. When users hit /feedback failures, they have no diagnostic trail to include in their bug
reports — only the generic terminal message they saw (a silent SHA or "Could not submit feedback. Please try again later."). Bug reports about /feedback are starved of
exactly the diagnostic data that would make them actionable.

This is a narrow, focused ask. It does not fix the underlying /feedback reliability issue (that's #46531 and the broader cluster referenced from there). It fixes the
information gap that compounds the reliability issue: right now, when /feedback fails, nobody can tell you anything about why, because the failure is invisible to the
only tool (~/.claude/debug/) that users have for diagnosing Claude Code problems.

Evidence

From @ert485's comment on #10905 (the canonical /feedback broken-for-months ticket):

▎ "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. It would help if the error details were logged there so users can provide more useful bug reports when
▎ the submission fails."

That's a specific, actionable observation from a user who has been debugging the failure directly.

Expected behavior

When /feedback is invoked and attempts a network submission, log the following to ~/.claude/debug/ in the same format used for other API calls:

• The HTTP request (URL, method, headers with auth redacted, body size)
• The HTTP response (status code, headers, body)
• Any exception or error thrown client-side (stack trace, error type)
• A timestamp and session/request identifier for correlation

On success: log the request + response as usual.

On failure: log the request + failure reason + any error details. This is the critical case.

Why this matters

• Users filing bugs about /feedback have no diagnostic data. Bug reports on #10905, #12638, and similar are full of "it says this message and then nothing happens" —

with no concrete signal the triage team can use to narrow down the cause. Debug logging would turn those reports into "it returned 503 with this body at this
timestamp."

• This fix is small and independent. Adding a network-request log line to an existing logging path is hygiene, not architecture. It can ship before any bigger /feedback

redesign.

• It compounds other fixes. Once users can include real network data in their bug reports, the broader /feedback investigation gets unblocked.
• Consistency. API calls, tool use, and hook events are already logged. /feedback being the one exception is a gap in an otherwise consistent diagnostic posture.

Scope

This is explicitly NOT a request to fix the underlying /feedback reliability issue. That's tracked in #46531 and the cluster of closed tickets it references (#10905,
#12638). This is the smallest imaginable separable fix that makes those other fixes land faster because users can finally report the bug with real diagnostic data.

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: (fill at submission — claude --version)

Related

• #46531 — broader /feedback comms gap and reliability issue (filed same reporter, same day)
• #10905 — canonical /feedback broken-for-months ticket (closed, auto-locked) — source of @ert485's observation
• #12638 — duplicate of #10905 with "Plugin source missing" diagnostic data
• #28565 — /feedback vs /bug naming mismatch

Environment Info

• Platform: darwin
• Terminal: ghostty
• Version: 2.1.101
• Feedback ID: 229cbbce-6d28-4390-8eb2-aeaecc192b6c

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 filtering p…

Note: Content was truncated.