[BUG] Claude Desktop (macOS): sustained mid-response connection drops + never-ending remote-tools-device reconnect storm, ~1 week, Desktop-only

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Desktop (macOS): sustained mid-response connection drops + never-ending remote-tools-device reconnect storm, ~1 week, Desktop-only

Summary

Since 2026-07-26, Claude Desktop on macOS has been showing "Request failed" with the
retry counter maxing out (commonly "retrying (6/10)" or similar) several times a day, every
day, through today (2026-08-06). The same account, same network, same machine, at the same
time, works fine in a browser session at claude.ai (Safari) — so this is not an account-wide
outage and not a network/ISP issue on my end.

In parallel, the app's remote-tools-device websocket (used for the phone-dispatch / Cowork
"work from your phone" feature) has been reconnecting 2,000–8,000 times per day for the same
week, non-stop, and I cannot get it to stay off — see "What I've tried" below.

Environment

• macOS 26.5.2, Apple Silicon (arm64)
• Claude Desktop app version 1.25927.0 (was 1.24012.9 earlier in the week; upgraded mid-week, no change in behavior)
• Bundled Claude Code CLI 2.1.219
• Network: home LAN, WiFi (802.11be, -43dBm signal, 0% packet loss to gateway and to 1.1.1.1/8.8.8.8), double-NAT (home router → ISP gateway), confirmed clean via ping/traceroute/curl — ruled out as a cause (see below)
• Auth: standard subscription OAuth, no ANTHROPIC_API_KEY set anywhere in shell/env

The failure signature

From ~/Library/Logs/Claude/main.log (or main1.log/main2.log etc. after rotation):

[CCD CycleHealth] <session_id> api_error (success): API Error: Connection closed mid-response. The response above may be incomplete.
[CCD CycleHealth] unhealthy cycle for <session_id> (<N>s, hadFirstResponse=true, reason=api_error)

hadFirstResponse=true on every single occurrence — the response starts streaming
normally, then the connection dies mid-flight. Durations before death vary wildly: 4s, 20s,
26s, 63s, 177s, 228s, 313s, 380s, 794s, 1427s, up to one 4,791s (~80 min) stall on 2026-08-05.
One explicit 529 Overloaded was also logged once.

Timeline (partial — every unhealthy cycle: api_error entry, 2026-08-01 through 2026-08-06)

2026-08-01 06:08:33  20s
2026-08-01 08:43:49  228s
2026-08-01 15:41:14  71s
2026-08-01 20:05:26  26s
2026-08-03 13:06:01  4s
2026-08-03 13:06:17  21s
2026-08-03 13:10:02  247s
2026-08-03 15:26:39  11s
2026-08-03 15:31:55  313s
2026-08-04 06:08:41  38s
2026-08-04 08:05:41  20s
2026-08-05 09:46:38  52s
2026-08-05 09:57:43  19s
2026-08-05 10:19:30  195s
2026-08-05 10:25:35  380s
2026-08-05 11:31:59  205s
2026-08-05 11:36:15  4791s
2026-08-05 11:52:16  1427s
2026-08-05 19:09:52  63s
2026-08-06 10:11:11  177s
2026-08-06 14:18:25  3357s
2026-08-06 14:49:51  26s
2026-08-06 14:59:51  2094s
2026-08-06 15:17:49  794s

(all hadFirstResponse=true, reason=api_error)

The remote-tools-device reconnect storm (possibly related, possibly a separate bug)

Same log, tag [remote-tools-device], connecting to
wss://bridge.claudeusercontent.com/devices/<org>_<account>/<device-name>/bridge:

2026-08-01: 6,582 reconnects
2026-08-02: 3,330
2026-08-03: 2,071
2026-08-04: 7,370
2026-08-05: 7,068
2026-08-06: 6,043 (partial day)

Typical cycle, repeating every ~10-15 seconds continuously:

connecting wss://bridge.claudeusercontent.com/devices/.../bridge
authenticated
socket closed: 1006
reconnect #1 in 1000ms

1006 is an abnormal-closure WebSocket close code (no close frame from the peer) — this is a
real connection failure, not a clean disconnect.

What I've tried, none of which stopped it

1. Removed preferences.remoteToolsDeviceName from claude_desktop_config.json directly and

restarted the app. On relaunch, the app silently wrote a brand-new device name back into
the same key (mac-lan → michaels-macbook-pro-local → mac across three attempts) and the
reconnect storm resumed within seconds each time.

1. In Settings → Cowork, turned **both "Dispatch" (Beta) and "Run new tasks in the cloud" to

OFF**, then fully quit and relaunched the app. Confirmed via config file that
coworkScheduledTasksEnabled reverted to true on relaunch regardless of the UI toggle
state, and the remote-tools-device reconnect storm resumed at the same ~10-15s cadence
within 15 seconds of app start.

1. Removed all paired/remote devices from the account. No effect — the storm is this Mac

registering itself, not something driven by other paired devices.

1. Terminated all other sessions except one Desktop session and one claude.ai browser tab —

no effect.

In short: there does not appear to be any way to durably disable the remote-tools-device
bridge from this end, on macOS, as of app version 1.25927.0. Every mechanism I could find
(config file, Settings UI toggle) is either overwritten on the next launch or has no effect on
the underlying reconnect behavior.

What I ruled out (so this isn't wasted triage time on your end)

• Local network: WiFi signal/noise pristine, 0% packet loss to gateway and to public

resolvers, zero interface errors, TLS handshakes and both large uploads (300KB) and large
downloads (50MB, sustained 6-10MB/s) complete cleanly with no mid-stream drops

• Path MTU: real path MTU is 1480 and oversized ICMP-with-DF is silently dropped (no "frag

needed" returned) — looks like a classic PMTU black hole but isn't the cause; TCP is
correctly MSS-clamped (proven by the large-transfer tests above)

• Proxy / VPN: none active (VPN client installed but disconnected)
• TLS interception: no injected root CA in the System keychain
• ANTHROPIC_API_KEY override: not set anywhere, so this isn't hitting a different tier/quota
• Disk / memory: >400GB free, 56%+ free RAM throughout
• OAuth: token cache healthy, no 401s, no re-auth churn around the failure windows

Why I think this is worth Anthropic engineering time specifically

1. It is Desktop-app-specific — the identical account, on the identical network, at the

identical time, does not reproduce this in a claude.ai browser session.

1. Every single failure has hadFirstResponse=true — these are not connection-establishment

failures or auth failures, they are established streaming responses getting cut off partway.

1. The remote-tools-device bridge instability (constant 1006 aborts) has run continuously

for the same ~10 day window as the chat-response failures, on the same app instance, and I
cannot find any user-facing way to disable it to test the correlation in isolation.

1. Given how long this has been ongoing and how often it fires, I'd guess it's affecting other

users on this app version too, not just me.

Repro / what to check

• Any macOS Desktop install left open for an extended session, ideally with Cowork features

enabled, should reproduce the remote-tools-device reconnect loop within minutes — grep
~/Library/Logs/Claude/main*.log for socket closed: 1006.

• Whether that reconnect loop is contending for the same connection pool / event loop / rate

limit as the main CCD chat session would be the thing I can't check from outside the app —
that's the part I'd most want engineering eyes on.

Happy to provide full log excerpts, HAR-style network captures, or run additional diagnostics
if there's a channel to submit them through.

What Should Happen?

It should just work!

Error Messages/Logs

Steps to Reproduce

I've no idea what you're talking about.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_