Desktop: sessions spawned by scheduled tasks missing from Recents and unpinnable (Search-only); Routines sidebar section intermittent

[Milesenberg]

Environment

• Claude Code desktop app on Windows 10 Home (10.0.19045)
• Observed on v1.21459.3 and still present immediately after relaunch-to-update on 2026-07-16 (latest build available that day)
• Heavy scheduled-task usage: ~16 recurring tasks (a nightly fleet of 12 firing 03:03–04:02 local, plus daily/weekly others) and frequent one-time tasks; sessions are local, with remote-control auto-start enabled
• Same machine/setup as Remote Control: long-idle desktop-app sessions go stale — mobile shows "Connected" but submitted prompts silently vanish after ~60s #77252 (remote-control disconnects), filed 2026-07-13

What happens

1. Sessions created by scheduled tasks (both cron and one-time fireAt) never appear in the Recents sidebar list — including sessions the user has already opened and exchanged messages with from the mobile app. Interacting with a spawned session does not surface it either.
2. These sessions cannot be pinned — no working pin affordance is offered for them.
3. They ARE returned by Search, and the session-management MCP (list_sessions) returns them with correct metadata — the sessions exist and are healthy server-side. This looks like a sidebar/session-index gap, not data loss.
4. Related wobble: the "Routines" collapsible sidebar section (shown parallel to Pinned/Recents) appears on some launches and is absent on others — e.g., present before a relaunch-to-update, gone immediately after it, on the same day.

Impact

With a daily scheduled fleet, effectively none of the user's working sessions are visible in the sidebar. Every navigation goes through Search by remembered title, and pinning — the natural workaround — is unavailable for exactly the affected sessions. The dedicated Routines page lists the tasks, not the sessions they spawn, so it doesn't substitute.

Repro

1. Create a scheduled task (cron or one-time fireAt) whose prompt runs a normal interactive session.
2. Let it fire; confirm the spawned session exists via Search or the session-management list_sessions.
3. Interact with that session (e.g., reply from the mobile app).
4. Check the desktop sidebar: absent from Recents; pin unavailable; Search finds it.

Expected

Recents should be all sessions ordered by last activity, including task-spawned ones. At minimum, any scheduled session the user has interacted with should appear in Recents exactly like a hand-started session. Ideally, scheduled runs with no user interaction yet would be collapsible/filterable within Recents so nightly fleets don't flood the list.

Possibly related

• Remote Control: long-idle desktop-app sessions go stale — mobile shows "Connected" but submitted prompts silently vanish after ~60s #77252 — remote-control sessions disconnecting/visibility issues on this same setup.
• Same-day observation: a task-spawned session appeared "archived"/vanished in the mobile UI while backend metadata showed it active and un-archived.

[kcarriedo]

Hitting the same gap with scheduled-task sessions and Recents. The pattern is consistent: sessions created by the scheduler run fine and are accessible via mobile (you can see them, message them, they respond), but they never appear in Recents on desktop and can't be pinned. You find them through Search or not at all.

The "Routines" sidebar section intermittency makes it worse - when it disappears, scheduled-task sessions have no navigation surface at all unless you remember the exact session title to search for.

A few things I've noticed that might help narrow the root cause for the team:

• Sessions opened via remote-control from mobile do sometimes surface in Recents after the fact. The common thread with sessions that don't appear in Recents seems to be that they were initiated by the scheduler (never manually opened first) and never had the Desktop app in focus while they were running.

• The issue appears to be session lifecycle metadata: scheduled sessions may not be registering a "user opened this" event that populates Recents, since they're launcher-initiated rather than user-initiated from the Desktop UI.

• On the pinning side: the pin action presumably requires a session to be in a "user-visible" state. If the session was never in Recents, the pin action may have no surface to attach to.

The workaround I use for the nightly fleet is keeping a plain-text manifest of session IDs/names and searching manually, but that's not a real fix. The right behavior is that any session a user has interacted with (even via mobile) surfaces in Recents on desktop.

[Milesenberg]

Thanks Kyle — this matches exactly what I'm seeing. My setup is a nightly fleet of ~12 scheduler-created sessions, and the pattern is identical: they run fine and I can reach and message them from mobile, but on desktop they never land in Recents and can't be pinned — Search is the only way in.

Your lifecycle-metadata theory lines up with that. The ones that never surface are purely scheduler-initiated and never had the desktop app focused while running; the odd session I've remote-controlled from mobile has occasionally shown up in Recents afterward, which fits the "user opened this" event never firing for the rest.

I've ended up on the same workaround — a plain-text manifest of session IDs/names I search by. It works, but agreed it isn't a real fix. The behavior I'd want is that any session I've interacted with, even via mobile, registers as user-visible and surfaces in Recents on desktop.

[hanjunjeong]

Seeing the same issue on the Claude Android app: a session spawned by a routine shows up in the Code tab session list, then disappears on a later visit — even though the routine's run history at claude.ai/code/routines still shows it as an active/completed run. No search feature in the Android Code tab to work around it, so the session becomes hard to find again once it drops off the list.

[Milesenberg]

Adding a mechanical finding from today, because I think two distinct disappearance mechanisms are being conflated in this thread and only one of them is a bug. Separating them should save some triage effort.

(1) The Routines sidebar renders only enabled tasks

A one-time task auto-disables the instant it fires — documented scheduler behaviour. So a scheduled one-off is listed in Routines while it is armed, and vanishes the moment it actually runs, taking its Runs history out of reach with it.

Verified on my install today: 141 tasks exist, 48 of them enabled. Three one-time tasks were visible in the sidebar while still armed; another disappeared from the list immediately after firing, while its session remained alive and reachable through session search.

This is not the defect in the title, but it produces an identical user experience — "I know that session ran and now there is no surface for it" — so it is worth naming explicitly rather than letting it absorb attention meant for the real bug.

(2) Sessions are not being archived

Worth killing as a hypothesis, since it is the natural assumption when things vanish. Of the 60 most recent sessions on my install, 58 report isArchived: false, and the only two archived were archived deliberately. Whatever removes scheduled sessions from Recents, it is not archival.

Scale, and the workaround

This bites hardest with a large roster — mine is roughly 14 recurring scheduled tasks plus a handful of one-offs a day. The practical workaround is the one already mentioned above: keep an external plain-text log of every task spawned, because the UI is not a reliable record of what ran. That works, but it means the app's own history is not trustworthy for the exact workflow scheduled tasks are meant to enable.

Related — same family

#81568 — session read/unread state is per-device and does not sync desktop ↔ mobile.

The common thread across this issue, #81568, #78679 (pins never surface on mobile) and #75343 (session names differ across surfaces) is session state that is account-level in some fields and per-device or per-surface in others. Archive state syncs correctly everywhere; Recents membership, pin state, read/unread and display name do not. If they share a root cause, the lifecycle-metadata theory in the comment above — launcher-initiated sessions never registering a "user opened this" event — would explain several of them at once.

[Milesenberg]

@hanjunjeong's report is worth pulling out, because it moves this off platform:windows.

Theirs is on the Claude Android app: a routine-spawned session appears in the Code tab session list, then is gone on a later visit, while the run history at claude.ai/code/routines still shows that run. Two things follow from that.

1. The label set may be under-scoping this. This issue is currently platform:windows, and my original report is a Windows desktop one. A same-shape report on Android suggests the defect sits in shared session-list membership rather than in the Windows client specifically.

2. It is a third variant, distinct from both mechanisms I separated above. Mine were (a) the Routines sidebar rendering only enabled tasks, so a one-time routine vanishes the moment it fires, and (b) archival, which I ruled out. Theirs is neither: the session was in the list, then left it, while the server-side run record survived. That combination is the informative part — the record exists and only the client's list membership is lost, which is hard to explain with anything other than per-surface session-list state.

@hanjunjeong — was the routine that spawned it recurring or one-time? If one-time, (a) would account for the routine-side half of what you saw and leave the session-list half unexplained, which is worth knowing before these get merged into one cause.

Worth emphasising the compounding factor you named: there is no search in the Android Code tab. On desktop, search is the workaround this entire thread depends on — it is how every one of us still reaches these sessions. Without it, a session that drops off the list has no remaining surface at all.

[NievesRojo]

Still present on macOS — same behavior, plus a detail that may point at the filter.

Environment: Claude Code desktop app on macOS (Darwin 25.5.0), CLI 2.1.237, model Opus, Anthropic API. Local sessions, mix of one-time fireAt tasks.

Extra data point — the discriminating field. I diffed the app's own session records in
~/Library/Application Support/Claude/claude-code-sessions/<...>/<sessionId>.json: a
task-spawned session that is hidden from the sidebar differs from a visible hand-started
session by exactly one extra key, scheduledTaskId. Nothing else marks it (no isArchived,
no hidden flag). So this reads less like a stale session index and more like the
Recents/date-group filter excluding any record that carries scheduledTaskId — the data is
present and correct, list_sessions returns it with accurate isRunning/lastActivityAt.

Additional symptom for one-time tasks. A one-time fireAt task auto-disables the moment
it fires, which also removes it from the Routines section. Combined with the Recents
exclusion, a one-time routine has no click path anywhere in the sidebar — including while
its session is still actively running. Recurring tasks at least keep a Routines row.

Workaround, for anyone else hitting this. Re-arm the fired one-time task with a future
fireAt (update_scheduled_task re-arms and auto-enables), and it reappears under Routines.
The cost is real: it will genuinely run again unless you cancel it before then. Editing the
session record to drop scheduledTaskId looks like it would work but is blocked by the
permission classifier, and patching app.asar is not viable.

Expected: as filed — task-spawned sessions in Recents ordered by last activity, and at
minimum a way to reach the currently running session of a routine from the sidebar.