Desktop: resuming a completed scheduled-task session (hosted on another machine) shows "Remote Control disconnected" after a long wait — no read-only state, no session-type indicator

Summary

Scheduled-task sessions (created by a recurring task via the Desktop "Routines" / scheduled-tasks feature) appear in the Desktop session list on every machine signed into the same account. When such a task runs as a local task — hosted by the Desktop app on the machine where it was created, with local-file access — its session is still surfaced account-wide through the shared session index.

Opening/resuming one of these completed sessions from a different machine causes the Desktop app to attempt a Remote Control connection back to the originating machine's session process, which has already finished. After a ~2–3 minute wait it fails with a misleading error:

"Remote Control disconnected — Your terminal's Claude Code session stopped responding. Check your terminal for errors, then resend your message."

There is no way to tell, before clicking, that the session is hosted on another machine and is no longer resumable.

Environment

• Claude Code Desktop on Windows 11 Pro, two machines under the same account
• Session created by a recurring scheduled task ("routine") on machine A, viewed/resumed on machine B

Steps to reproduce

1. On machine A, create a recurring scheduled task that runs as a local task (Desktop app hosts execution, with local-file access).
2. Let it run several times. Each run appears as a session in the Desktop list — and, because the session index is account-scoped, on machine B as well.
3. On machine B, open one of those completed sessions and send a message to continue it.
4. Wait ~2–3 minutes → "Remote Control disconnected" error.

Two UX gaps

1. No indicator of session type / host. Local, account-shared, and remote sessions are mixed into one list with no icon or badge. There's no way to tell that an entry is hosted on another machine (or is a completed scheduled-task run) and will behave differently when clicked.
2. No read-only state for completed, non-resumable sessions. Once the originating session process is gone, resuming is impossible — yet the input stays active: it accepts a message, hangs for 2–3 minutes, then returns a terminal-focused error that doesn't describe what actually happened.

Expected
A completed scheduled-task session that cannot be resumed should open as a read-only transcript, carry a clear indicator of its type/host (e.g. "scheduled task", "hosted on <machine>"), and offer a "Continue in a new session" action instead of silently attempting a Remote Control attach that times out.