submitFeedback always fails with failure=network_error while every other endpoint works — in-app bug reporter unusable (Desktop, bundle 2.1.219)

Related: #82242 (separate bug — turns failing on network path change; that investigation
is how this one surfaced). Support incident d2142d0e-0119-4c35-a18d-761171637be4.

Environment: Claude Code bundle 2.1.219 inside Claude Desktop, macOS (Darwin 25.3.0),
Apple Silicon. Log: ~/Library/Logs/Claude/main.log.

Summary

LocalSessions.submitFeedback fails every time with feedback_id=null,
failure=network_error, while every other network call the app makes succeeds seconds before
and after. The network is not the problem, and the reported error is false. Six consecutive
attempts across two separate processes (the app was restarted mid-sequence to rule out
stale state) all failed at a uniform 15–16 second timeout.

The practical effect is that the in-app bug reporter cannot be used to file a bug, and it
tells the user their internet is at fault, so they stop trying.

Evidence

All timestamps local, 2026-07-29, de-duplicated (the app writes every log line twice):

13:00:00  [CCD] LocalSessions.submitFeedback: descLen=4096
13:00:15  [CCD] Feedback submitted: feedback_id=null, failure=network_error     (15s)
13:00:30  [CCD] LocalSessions.submitFeedback: descLen=4096
13:00:45  [CCD] Feedback submitted: feedback_id=null, failure=network_error     (15s)

13:01:54  [CCD CycleHealth] healthy cycle (61s, hadFirstResponse=true)   <-- API TURN SUCCEEDED

13:03:15  [CCD] LocalSessions.submitFeedback: descLen=4096
13:03:31  [CCD] Feedback submitted: feedback_id=null, failure=network_error     (16s)

---------- 13:03:43 "Starting app" / 13:03:44 [CCD] Initialized with version 2.1.219 ----------
---------- APP RESTARTED to clear any stale state ----------

13:03:45  Successfully fetched blocklist from https://claude.ai/api/organizations/…/dxt/blocklist
13:03:45  [growthbook] loaded 236 features (236 changed)
13:03:47  [PluginsFetcher] fetchBrowsableRemotePlugins: 92 plugins
13:03:48  [EventLogging] Flushing 50 events                     <-- telemetry POSTs succeed
13:04:17  [updater] Checking for updates → https://api.anthropic.com
13:04:33  [CCD] Session warmed successfully in 807ms

13:04:38  [CCD] LocalSessions.submitFeedback: descLen=4096
13:04:54  [CCD] Feedback submitted: feedback_id=null, failure=network_error     (16s)
13:05:56  [CCD] LocalSessions.submitFeedback: descLen=4096
13:06:11  [CCD] Feedback submitted: feedback_id=null, failure=network_error     (15s)

What this rules out

• Not the network. A successful 61-second API turn sits between two failures in the first

process, and a 236s turn completed at 12:59:32. In the fresh process, five distinct
endpoints (claude.ai blocklist, growthbook, plugin catalogue, EventLogging,
api.anthropic.com updater) all succeeded in the seconds before submitFeedback failed
again. Other applications on the machine were unaffected throughout.

• Not stale client state. The restart rebuilds the Chromium socket pool,

NetworkChangeNotifier state and the OAuth token cache. Behaviour was identical before and
after.

• Not transient. Six for six, spanning six minutes and two processes.

Two supporting details

Uniform latency. Failures take 15, 15, 16, 16, 15 seconds. Genuine network failures
scatter; this consistency indicates a fixed client-side timeout being reported as
network_error.

descLen=4096 on every attempt — exactly 2¹². The description field appears to be capped
at 4096 characters, so a detailed report is silently truncated before submission. Worth
confirming whether the cap is client-side and whether an over-length body contributes to the
failure.

The diagnosability problem

The client logs no URL, no HTTP status and no response body — only network_error. It is
therefore impossible to distinguish:

• a 413/400 rejecting the 4096-byte payload,
• an auth-scope rejection for the feedback endpoint specifically,
• a server-side hang hitting the client timeout,
• an actual transport failure.

This should be fixed first, because it blocks triage on your side as much as mine.

Why this matters more than a single broken form

Whatever share of users hit the class of bug in #82242, Anthropic cannot measure it,
because the channel for reporting it is this one. The failure message blames the user's
connection, which is exactly the conclusion a non-technical user will accept before giving
up. I only established that my own connection was fine by correlating five log rotations
against my commute schedule; nobody should need to do that to file a bug.

I previously attributed 12 failed submissions on 2026-07-28 (07:12:29–07:17:35 and
17:45:02–17:52:24, all feedback_id=null, failure=network_error) to a concurrent roaming
outage. Given today's evidence they were probably always this defect.

Requested changes

1. Log the real outcome — URL, HTTP status, response body, and distinguish timeout from

transport failure. Stop reporting every failure as network_error.

1. Persist submissions to disk and retry with backoff, so a report survives a genuine

outage or an app restart instead of being lost.

1. Fix the endpoint failure itself once (1) makes it diagnosable.
2. Surface the 4096-character cap in the UI, or raise it. Silently truncating a bug report

is worse than rejecting it.

1. Tell the user the truth on failure — "we couldn't submit this, it's saved and we'll

retry" rather than "check your internet connection".

Reproduction

1. Claude Desktop, bundle 2.1.219, macOS, healthy network connection.
2. Open the in-app bug reporter, paste a description of roughly 4000+ characters, submit.
3. Observe ~/Library/Logs/Claude/main.log:

[CCD] Feedback submitted … feedback_id=null, failure=network_error about 15s later.

1. Confirm the network is healthy — other endpoints in the same log succeed within seconds.
2. Restart the app and repeat: identical result.

grep -hE 'submitFeedback|Feedback submitted' ~/Library/Logs/Claude/main*.log | sort -u

Happy to run a --log-net-log capture or provide the full log excerpt if that helps.