[BUG] Large sessions silently stop syncing to web/mobile, then fail to unarchive — host process running and connected throughout

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?

Bug report: large sessions silently stop syncing to cloud clients, then fail to unarchive

Summary

Two Claude Code sessions hosted on a remote Linux machine progressively became
invisible to all cloud clients (web, mobile) while the local host process stayed
healthy and connected. Both later appeared in Archived and cannot be restored.
The restore error blames the originating computer's Remote Control connection,
which was demonstrably up at the time.

Environment

• Host: Debian 13, Claude Code ccd-cli 2.1.234, installMethod native
• Session hosted on a remote machine, driven from a desktop on the same LAN
• Host machineID: 5e6cc69e10e38994ba73a962a02c95c9d08ab87d6406592a3fb4b5b4433cd3be
• Clients affected: claude.ai web, mobile app
• Client unaffected: direct SSH terminal session into the host

Symptoms, in order

1. Session works normally from laptop and phone, including notifications.
2. After extended work, the session stops appearing on web and mobile and stops

sending notifications. No error is shown at the moment this happens.

1. The session later appears under Archived.
2. Unarchiving fails with "error restoring session" plus "Remote control on the

originating computer is no longer connected."

1. Refreshing does not help. The session remains fully usable from the direct

terminal path throughout.

Evidence gathered on the host

• Host process healthy the whole time, with live outbound TLS connections to

Anthropic held by ccd-cli (observed against 160.79.104.10:443 and
34.149.66.165:443).

• Local session state contradicts the cloud: the session-management API on the

host reports isArchived: false for a session the cloud shows as archived.

• Transcript sizes are the only property distinguishing the two failing sessions

from every healthy one:

| session | total | largest single event |
|---|---|---|
| failing session 1 | 13.7 MB | 942 KB |
| failing session 2 | 2.4 MB (910 events) | 54 KB |
| next largest healthy session | 154 KB | - |

• Only cloud-relayed clients are affected. The direct terminal path into the same

host is unaffected, which points at the sync/relay layer rather than at
connectivity, auth, or the host process.

Two concrete asks

1. The error text misattributes the cause. "Remote control on the originating

computer is no longer connected" reads as "your machine is offline." The
machine was online and connected. Whatever condition is actually being checked
should be named, because this message actively misdirects diagnosis.

1. Failure is silent at onset. There is no indication when a session stops

syncing; it is only noticed later when it has vanished from other clients. A
surfaced warning at the point of first sync failure would have made this
self-evident.

Relation to existing issue #60790

GitHub issue anthropics/claude-code#60790 reports the same error string, attributed
there to the bridged Claude Code process on the host having stopped responding or
exited.

This case is different, and that difference is the point. The host process did
not exit. Throughout the failure it was running and holding live outbound TLS
connections to Anthropic, and the direct terminal path into the same host stayed
fully usable. So either the liveness check behind this error is reporting a healthy
host as disconnected, or the same message is being reused for a second, distinct
condition. Either way it is not a duplicate of #60790.

Documentation gaps this exposes

Checked against current docs (sessions, remote-control, claude-code-on-the-web,
troubleshooting):

• No documented limit on transcript size, per-message size, or event count for

cloud sync. If a threshold exists, it is undocumented — which is why this failed
silently and was diagnosed only by comparing file sizes across sessions.

• No documented way to force a resync of an existing session.
• No documented recovery path for an archived session that fails to restore.
• The error string itself is not in the error reference, and no troubleshooting

entry explains what condition triggers it or which machine "the originating
computer" refers to when the session is hosted remotely.

What could not be determined locally

No local logging covers the sync layer. remote-server.log records only process
spawning, so there is no host-side evidence of what the sync attempt did or why
it failed. If there is a documented transcript size limit, or a supported way to
force a resync of an existing session, neither is discoverable from the host.

What Should Happen?

Sessions should be able to maintain their Remote Control functionality.

Error Messages/Logs

Steps to Reproduce

unknown

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.32885.1

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_