[BUG] Cowork: coworkd_upstream_failed / connection refused on 160.79.104.10:443 — recurring 2+ days

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?

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (related: #40996)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Desktop / Cowork

What's Wrong?

For the past 2+ days, Cowork tasks fail to complete. Sessions repeatedly error out with the same upstream connection failure to the same backend IP, suggesting a specific upstream worker / endpoint is down or refusing connections — but it is not consistently affecting all users, so it has not appeared on status.claude.com.

Error

API Error: 587 {"error":"coworkd_upstream_failed","category":"connection_refused","detail":"dial tcp 160.79.104.10:443: connect: connection refused"}

The IP 160.79.104.10:443 is identical across every failure, which strongly suggests a single broken upstream node rather than transient network issues on my side.

Frequency

• Started: ~April 17, 2026
• Still occurring: April 19, 2026
• Multiple failures per day, intermittent (some sessions succeed)
• Restarting Claude Desktop does not help

Environment

• OS: macOS
• Node: v24
• Network: residential / no VPN / no corporate proxy
• Region: Prague, CZ
• Regular Claude.ai chat works fine — only Cowork is affected

Expected Behavior

Cowork session should connect to a healthy upstream worker and complete the task without the connection being refused.

Notes

This appears related to issue #40996 (also coworkd_upstream_failed, March 30, 2026). The pattern looks like one or more upstream workers in the Cowork pool are unhealthy but not being removed from rotation, so requests routed to them fail deterministically while others succeed.

What Should Happen?

Cowork session should connect to a healthy upstream worker and complete the task without the connection being refused.

Given that the failure occurs deterministically on the same backend IP (160.79.104.10:443) across multiple days and sessions, the upstream load balancer should detect the unhealthy node and remove it from rotation, so requests are routed only to working workers.

Error Messages/Logs

API Error: 587 {"error":"coworkd_upstream_failed","category":"connection_refused","detail":"dial tcp 160.79.104.10:443: connect: connection refused"} · check status.claude.com

API Error: 587 {"error":"coworkd_upstream_failed","category":"connection_refused","detail":"dial tcp 160.79.104.10:443: connect: connection refused"} · check status.claude.com

Steps to Reproduce

1. Open Claude Desktop on macOS (Node v24 environment).
2. Start a new Cowork session.
3. Issue any task that requires the Cowork backend to execute (e.g. "create a file" or run any tool call inside Cowork).
4. Within seconds, the session fails with:

API Error: 587 {"error":"coworkd_upstream_failed","category":"connection_refused","detail":"dial tcp 160.79.104.10:443: connect: connection refused"}

1. Close the session and start a new one. The error reproduces intermittently — some sessions connect successfully, others fail immediately on the same IP (160.79.104.10:443).
2. Restarting Claude Desktop does not resolve it.
3. Switching network (Wi-Fi → mobile hotspot) does not resolve it, confirming the issue is not local.

No specific code or files are required — the failure happens during Cowork sessio

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Opus 4.6.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Pattern observation

The failing IP is identical across every occurrence over 2+ days:

160.79.104.10:443

This is not random network flakiness — connection refused (as opposed to timeout, reset, or DNS failure) means the TCP SYN reached the host but no service was listening on port 443, or the service actively rejected the connection. Combined with the fact that other Cowork sessions from the same client succeed, this points to one (or a small number of) unhealthy backend node(s) still receiving traffic from the load balancer.

Related issues

• #40996 — coworkd_upstream_failed / tls: bad record MAC (March 30, 2026) — same error class, different failure mode (TLS handshake), suggesting recurring instability in the Cowork upstream pool over the last several weeks.

Status page

status.claude.com currently lists Cowork as Operational (99.5% uptime over 90 days). This incident is not reflected there, likely because the failure is partial / per-node and the aggregate success rate stays above the alerting threshold.

Logs

Happy to attach ~/Library/Logs/Claude/ logs (claude.ai-web.log, coworkd.log) on request — let me know which files and time window would be most useful and I will upload them.

Impact

Blocking ongoing development work on a multi-file project. Workaround is running tasks via Claude Code CLI directly, but this defeats the purpose of using Cowork for longer agentic flows.