[BUG] Live macOS Desktop session missing from iOS app and from Dispatch list_sessions API (not just UI-level archive filtering)

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?

A session created interactively in the Claude Desktop app on macOS — live, actively browsable, and up to date on the Mac itself — is not visible from other surfaces tied to the same account:

1. iOS Claude app (Dispatch tab): the session either does not appear at all, or appears under "Archived" showing content frozen at an earlier point than what the Mac currently displays. This has happened twice in one day with two different sessions, on the same account/setup.
2. Dispatch orchestrator list_sessions (session-management MCP): a call to list_sessions from a Dispatch orchestrator session does not return this session at all — not archived, not live, just absent. This is the more important data point: it's not a UI filter hiding something the backend has, the session-listing API itself omits it.

Critically, this is not a blanket "user-created sessions are hidden" problem: other user-created sessions (is_child: false, not spawned by any scheduled task) from the same account appear correctly in the same list_sessions response, with correct metadata. Only specific sessions are dropped, and the affected session was not idle or finished — it was a session the user was actively working in on the Mac at the time.

This also isn't explained by the one auto-archive behavior that's actually documented: Settings → Claude Code → "Auto-archive after PR merge or close" (default: off), which only applies to local sessions whose run has finished. There's no documented policy for archiving-on-disconnect or omitting a session from a cross-device listing API.

Unarchiving isn't possible from the UI when a session does end up archived (tracked separately as a feature request in #30869 / #62428 / #67835), and archived sessions can't receive new messages, so when this happens the session is effectively stuck on whichever device still has it live.

What Should Happen?

• A session that is live on one surface (e.g. Desktop) should be discoverable and resumable, with current state, from every other surface tied to the same account — per the documented behavior that remote sessions are account-scoped and any surface can reopen/resume a session started on another surface.
• A session should never be silently dropped from a session-listing API (list_sessions) while it is still live elsewhere. If it's archived, it should say so and be returned as archived, not omitted.

Steps to Reproduce

1. On macOS, in the Claude Desktop app, start a new session and interact with it normally (not via a scheduled/routine task — a plain interactively-created session).
2. Keep using the session on the Mac; confirm it's live and its content is current there.
3. On an iPhone, open the Claude app → Dispatch tab, and look for the same session.

• Observed: the session is either missing from the list entirely, or shown under "Archived" with content stale relative to what's currently on the Mac.

1. From a separate Dispatch orchestrator session (any session with access to the session-management MCP tools), call list_sessions.

• Observed: the affected session is not present in the returned list at all.

1. In the same list_sessions response, check other sessions from the same account that were also created interactively (is_child: false) rather than spawned by a scheduled task.

• Observed: those sessions do appear, with correct metadata — so the omission is specific to certain sessions, not a global filter.

1. Repeat steps 1–4 with a different session later the same day.

• Observed: reproduced again, a second time, same day.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Not captured before filing — current Desktop app + iOS app builds as of 2026-08-10. Happy to grab exact version strings if a maintainer confirms which build info would help.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other (Claude Desktop app — not a terminal/CLI session; the affected surfaces are the Desktop app, the iOS app, and the Dispatch orchestrator's session-management MCP)

Additional Information

Environment: macOS 15.7.7 (Sequoia), MacBook Pro 13" (2019, Intel, T2 chip). Same account across Desktop and iOS.

Relationship to existing issues (checked each before filing, not a duplicate of any of them):

• #67811, #32651, #59449, #68972 (all closed) and #60043, #77252 (open) describe auto-archiving or disconnection tied to an idle timer — a session goes stale or archives after N minutes of no interaction, or a woken-but-stale session silently drops prompts. The session in this report was not idle — it was actively being used on Desktop at the time it was missing/stale on iOS.
• #45403 (closed, duplicate) is about deleted web conversations still showing as archived on mobile. Nothing was deleted here.
• #78229 (open) is the closest match: sessions spawned by scheduled tasks are missing from the Desktop sidebar, yet the backend (list_sessions and Search) return them correctly — i.e., a UI-only sidebar/index gap, not a backend data problem. This report is the inverse and, I believe, new information: the affected session here was not spawned by a scheduled task (a plain interactive Desktop session), and it's missing from the backend list_sessions API response itself, not just a sidebar index. So #78229's finding ("backend has it, UI hides it") does not explain this case ("backend doesn't return it either").

Given the pattern across all of these reports, there appear to be at least two distinct bugs in this area: (a) idle/disconnect-driven archiving that's more aggressive than documented, and (b) session-listing/indexing gaps that omit specific sessions from clients and from the list_sessions API regardless of idle state. This report is evidence for (b) with a reproduction path that doesn't depend on waiting out an idle timer.