Projects: coordinator reports idle-recycled local thread as "Mac offline" though the Mac is online and the thread resumes in seconds

Summary

In a Project (Claude Code desktop app, threads running locally via Remote Control), the coordinator told me my Mac was offline and the thread would only start after the Mac reconnected. The Mac was online the whole time. The thread had only been recycled by the desktop app's idle sweep, and it was already running again a few seconds after my message arrived. The coordinator's wording ("Mac offline", "wait for reconnect") is misleading and can make the user think work is blocked.

Environment

• Claude Code 2.1.291, macOS desktop app (Code tab), Max plan
• Project threads running on the local Mac; the coordinator replied from the project chat

What happened (local time, PDT, 2026-10-10)

• 10:21:11: the app's idle sweep stopped the thread's session after about 1 hour idle (stopping session (idle) -> session ended (stopped -> idle, unarchive queued)).
• 11:55:31: I sent a message ("deploy"). The app logged redispatch requested, then admitted (resume, nudge poll), and attached at 11:55:36.
• The coordinator's reply to me said the Mac was offline and the thread would wait for it to reconnect.
• 11:55:52: the thread had already started the job. At 12:02 I asked "is the Mac online, can it deploy?" and the thread answered it was online and already running.
• The Mac had no system sleep events that day (display off only, pmset -g log), and Claude held a no-idle-sleep assertion the whole time.

Expected

The coordinator should not describe an idle-recycled thread as "Mac offline". Either wait for the resume, which takes seconds, and report the real state, or say something like "thread was idle and is being resumed automatically".

Actual

The coordinator reported a stale pre-resume state ("offline / suspended, waiting for the Mac"). The user cannot tell whether the command was delivered or whether anything needs to be done.

Suggestion

• When forwarding to a thread whose session was stopped by idle sweep, trigger the resume first and report the post-resume state.
• Distinguish "recycled for idleness, resuming" from "Mac actually unreachable" in the coordinator's status wording and in the thread status shown in the UI.

Related

The docs say a local thread "pauses while that computer is asleep, and stops if the desktop app quits", which does not describe the idle-recycle case. Maybe worth adding a note there.