[BUG] claude --resume silently returns a PARTIAL transcript: remote-control/phone turns are never written to local disk → overnight work lost with no error (+ sessions booted while credit-limited never register for remote control)

Summary

Two remote-control / session-persistence defects hit in one incident this morning. The first is a silent data-loss bug that I think is serious enough to warrant its own thread.

Defect A — claude --resume silently returns a PARTIAL transcript. When a local CLI window ends (in my case an overnight re-authentication ended the local session) and you keep the same conversation going from your phone via remote control, those remote-control turns are stored server-side only — they are never written to the machine's local session transcript (~/.claude/projects/<project>/<UUID>.jsonl). The local transcript simply ends at the last turn taken before the window closed. Every subsequent claude --resume <UUID> on that machine faithfully replays only what's on local disk — so the entire overnight of remote-control work is silently absent, with no error and no warning.

In my case that was an entire night of an agent's work — its decisions, several in-flight work lanes, and an unanswered queued question — that existed in exactly one place: the conversation my phone was displaying. It was recoverable only because I happened to have screenshots; recovery meant manually transcribing those screenshots back into a local file to re-seed continuity. Without the screenshots it would simply be gone — and I'd never have known which turns were missing, because --resume reports success.

Defect B — sessions booted while credit-limited never register for remote control. Separately, several sessions that had booted while my plan was in a limited / credits-prompt state registered for remote control exactly once and never retried → they stayed invisible to the phone / remote control permanently, even after the plan returned to normal. They were reachable only by killing and re-launching them (a fresh boot registers correctly). This is what presented as "remote control isn't working."

Why Defect A is serious

This is the worst failure mode for an agentic workflow: silent loss of completed work on resume. --resume succeeding-but-incomplete is worse than --resume failing — when it fails (e.g. #33912) you know something is wrong; here nothing errors, so the loss is invisible until you happen to notice specific work is gone. Remote-control / phone turns are effectively "one-copy" data with no local durability and no warning that the local transcript is behind the server-side thread.

Steps to reproduce

Defect A:

1. Start a CLI session on your machine.
2. Let the local window end while the conversation is live (a re-auth prompt, a crash, or closing the terminal).
3. Continue the same conversation from your phone via remote control for several turns of real work.
4. Back on the machine, run claude --resume <UUID>.
5. Observed: the resumed transcript ends at the last turn taken before the window closed; every phone / remote-control turn is missing. No error, no indication the transcript is partial.
6. Expected: resume restores the full conversation including remote-control turns — or, at minimum, warns that the local transcript is behind the server-side thread.

Defect B:

1. Boot a session while the account/plan is in a limited / credits-prompt state.
2. Observed: the session never registers for remote control and never retries; it stays invisible to the phone even after the plan is back to normal. Only a fresh boot registers.
3. Expected: remote-control registration retries, so a session that booted in a limited state re-registers once the account recovers instead of being invisible forever.

The cost (why this isn't a minor edge case)

Recovering from these two defects consumed most of a Monday morning before I could touch my own project. On a weekly allowance that had just reset at 6:00 AM, by 7:15 AM I'd already burned 69% of the rolling session, ~22% of the weekly Fable allowance, and 14% of the all-models weekly allowance — and it kept climbing.

The composition is the insulting part: that Fable burn wasn't Fable doing anything — it was one window being relaunched over and over while the recovery agent tried to get the remote-control / resume state sorted (the rest of the recovery ran on Opus). It should not cost a meaningful slice of a weekly allowance to restart a single window. That is a retry loop billing me, not work — the same usage-vs-output disconnect tracked in #67506.

Environment

• Platform: Windows, recent CLI (2.1.21x-era).
• Remote control used from mobile; conversation continued cross-device.
• Screenshots exist but are described here rather than attached (they contain account/usage UI and unrelated private project content).

Related

• #77876 — background agent survives logout/re-login, invisible from the active session (the adjacent re-auth / remote-control-visibility cluster; Defect B is a different trigger — a credit-limited boot state, not logout survival).
• #77749 — --resume hangs when the local conversation exists but the remote-control session expired (adjacent --resume × remote-control interaction; different symptom — a hang vs a silent partial).
• #68606 / #36261 / #36401 — remote-control session persistence / resume-on-restart (the RC-persistence cluster this data-loss sits inside).
• #33912 — the inverse failure: --resume returns "No conversation found" (resume fails); here resume succeeds but returns a partial transcript.
• #67506 — Fable usage-vs-output disconnect (the "it shouldn't cost this much" angle).
• #79247 — weekend post-mortem; this is a concrete instance of its core point: usage spent recovering from platform bugs, not on my own work.