Desktop: sessions spawned by scheduled tasks missing from Recents and unpinnable (Search-only); Routines sidebar section intermittent
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 #77252 (remote-control disconnects), filed 2026-07-13
What happens
- 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. - These sessions cannot be pinned — no working pin affordance is offered for them.
- 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. - 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
- Create a scheduled task (cron or one-time
fireAt) whose prompt runs a normal interactive session. - Let it fire; confirm the spawned session exists via Search or the session-management
list_sessions. - Interact with that session (e.g., reply from the mobile app).
- 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
- #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.
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
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:
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.
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.
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.
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.
@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.