Desktop: finished same-machine scheduled-task sessions show permanent 'Remote Control disconnected' + blinking sidebar dot under 'Other' group

Status Open

Reported on v2.1.258

Maintainer reply None cached

Activity 3 comments · opened Sep 3, 2026

Summary

In the Claude desktop app (macOS, app-bundled Claude Code 2.1.258, macOS Darwin 27.0), every session created by a recurring scheduled task appears as its own row in the sidebar under an "Other" group (the group field is null). For finished one-shot runs, the sidebar dot blinks grey indefinitely, and opening the session shows:

"Remote Control disconnected — Claude Code on the computer running this session is offline… If Claude Code was closed, start it there again and reopen this conversation."

This happens even though the session ran entirely on the same machine, finished normally hours or days earlier, and its process exited cleanly. The banner and blinking persist across app restarts. With a 5-minute-cadence task this produces dozens of permanently-blinking rows per hour, making the sidebar unusable for finding anything else.

This looks related to #79057 (Remote Control disconnected on resuming a scheduled-task session from another machine) and #74875 (sidebar indicator pulsing gray while idle), but is distinct from both: it reproduces on the same machine that ran the task (no cross-machine resume involved), and it is specific to scheduled/recurring-task sessions rather than general idle sessions. Filing separately since neither existing report captures the "Other" grouping or the always-on remoteControlAutoEligible flag below; happy to have this merged if a maintainer judges it's the same root cause.

Measurements (macOS, local machine, 2026-09-03)

App-side session records live at ~/Library/Application Support/Claude/claude-code-sessions/<workspace>/<org>/local_<id>.json. Of 771 records on this machine, 595 have a scheduledTaskId. Of those 595, 321 carry a non-empty bridgeSessionIds array while no local process exists for them. (For comparison, 111 of the 176 non-scheduled records also carry a non-empty bridgeSessionIds, so this isn't unique to scheduled tasks, but it's far more common among them.)
Scheduled-task records carry a field remoteControlAutoEligible: true. Ordinary finished (non-scheduled) sessions do not have that field at all.
For one recurring task sampled in isolation: 43 of 45 records have a bridgeSessionIds entry, and 33 of 45 never recorded completedTurns. lastActivityAt equals createdAt on 12 of them (i.e., the record never got a second timestamp despite the task having run).
The CLI-side session registry (~/.claude/sessions) and the get_session API both report isRunning: false for these sessions — i.e., by every other signal the run is finished, only the sidebar/bridge state disagrees.
Reproduce: create any scheduled/recurring task on a short cadence (I used 5 minutes), let it fire a handful of times, then look at the sidebar. Each fire is its own permanently-blinking "Other" row.

Hypothesis (unconfirmed, still under independent check on my end): scheduled-task sessions are auto-enrolled for Remote Control bridging (remoteControlAutoEligible: true), and the bridge id (bridgeSessionIds) is left on the record after the one-shot process exits. The app then renders the disconnected-bridge state for a session that never had — or no longer has — a bridge to reconnect to, rather than recognizing the process exited cleanly and rendering it as done/idle.

Additional data point requested by my own review

I tried to compare the state claude agents --all --json assigns to a couple of scheduled-task sessions versus a normal finished session, but the command is unavailable on this machine right now — the globally-installed claude CLI errors with "claude native binary not installed" (missing postinstall / optional native dependency), independent of this bug. Noting this so it's clear that data point isn't in this report, rather than silently omitted.

Asks

A finished scheduled-task run should render as done/idle in the sidebar, not as a disconnected remote bridge, once the originating process has exited cleanly.
An option to fold recurring-task runs into a single sidebar row (or group them under something like "Routines") instead of creating one permanent "Other" row per fire — a 5-minute cadence currently produces dozens of stuck rows per hour.

Environment

Claude desktop app, macOS, app-bundled Claude Code 2.1.258
macOS Darwin 27.0

View original on GitHub ↗

3 Comments

jasonjwarren · 1 month ago

Correction to the hypothesis in the original report (independent check completed after filing; symptom unchanged, proposed mechanism withdrawn).

remoteControlAutoEligible is not the cause. The app's own policy gate reads remoteControlPolicyCovers(e){return !!e.remoteControlAutoEligible && !e.scheduledTaskId}, so the flag is inert for exactly the scheduled-task sessions this report is about. The flag is also set unconditionally on first turn, so it is a "first turn happened" marker, not an enrolment. Please disregard that part of the original text.

bridgeSessionIds is not a leaked/dangling value. The app reads it on session end/delete and issues a bridge delete ([LocalSessionManager] Requested CCR delete of N Remote Control bridge session(s) appears in main.log). It is a durable identifier the app keeps on purpose.

Bridging on these sessions comes from a user preference: claude_desktop_config.json has ccRemoteControlDefaultEnabled: true, and main.log shows [rcAutoEnable] verdict: enable=true source=explicit_pref on each run. That preference disagrees with ~/.claude/settings.json remoteControlAtStartup: false; the desktop pref wins.

The banner wording in the original report was transcribed from screen, not from the bundle. app.asar does not contain the string "Remote Control disconnected"; the nearest shipped caption is "Remote access ended. This session could not reconnect to the conversation it was started from…". Treat the quoted text as approximate.

What survives, and is the actual report: finished one-shot scheduled-task sessions are reported as done by both of the app's read-side surfaces (get_session → isRunning: false, isRemote: false; claude agents --json does not list them at all), yet the sidebar renders them as a blinking/reconnecting remote session under "Other", persistently, with a Remote Control ended-style banner on open. That is a renderer / state-sync issue for sessions that have no live process and never will. The ask stands: render such sessions as idle, and give recurring-task runs a group of their own instead of one "Other" row per fire.

jkap-el · 1 month ago

Since the desktop app auto-updated (Windows 11, MSIX install, app 1.40609.1.0 -> 1.44121.2.0, bundled Claude Code CLI 2.1.255 -> 2.1.258), sessions spawned by the built-in scheduler ([CCDScheduledTasks]) are never connected to Remote Control. Interactive sessions started from the desktop still connect normally and show up in the mobile app.
Global setting "Connect new sessions to Remote Control" is enabled. Fully quitting and reopening the app did not change the behaviour.

Evidence from %LOCALAPPDATA%\Claude\Logs\main.log:
Before the update (2 Sept, every scheduled spawn):
2026-09-02 14:39:37 [CCDScheduledTasks] Spawning new session for scheduled task ticket-triage-incremental
2026-09-02 14:39:37 [rcAutoEnable] verdict: enable=true source=explicit_pref trigger=first_turn
2026-09-02 14:39:37 Enabling remote control for session local_e1c52813-...
2026-09-02 14:39:40 [remote-control] bridge_state: "connected"

After the update (3 Sept, every scheduled spawn, e.g. 08:31, 09:09, 10:39, 11:09, 12:39, 13:09, 14:40):
2026-09-03 14:40:13 [CCDScheduledTasks] Spawning new session for scheduled task ticket-triage-incremental
2026-09-03 14:40:14 Starting local session local_50d972a8-...
2026-09-03 14:40:15 Mapping internal session local_50d972a8-... to CLI session 7fc88f46-...
(no [rcAutoEnable] line, no "Enabling remote control", no bridge_state line)

Interactive session on the same build, same folder, minutes earlier:
2026-09-03 14:15:25 [rcAutoEnable] verdict: enable=true source=explicit_pref trigger=first_turn
2026-09-03 14:15:25 Enabling remote control for session local_d91b492a-...
2026-09-03 14:15:27 [remote-control] bridge_state: "connected"

Impact: PushNotification calls inside scheduled sessions now return "Mobile push not sent (Remote Control inactive)", so the scheduled workflows can no longer send decision cards to the phone, and the scheduled sessions do not appear in the mobile app's Remote Control list.

Expected: scheduled-task sessions should get the same rcAutoEnable evaluation as interactive sessions when the "Connect new sessions to Remote Control" preference is on, as they did on 1.40609 / CLI 2.1.255.

redsand2 · 1 month ago

Confirming this reproduces on Windows too (this issue currently only has macOS evidence).

Environment: Windows 11, Claude Desktop, bundled CLI 2.1.260

A session created by one of my scheduled tasks (Routine) carries remoteControlAutoEligible: true
in its session record, even though the global "Connect new sessions to Remote Control" toggle had
already been off for some time when this session was created — every other local session created
that day from ~19:33 onward already correctly shows remoteControlAutoEligible: false:

scheduledTaskId: "idle-session-candidates"
createdAt: 2026-09-08T22:13:45 (local)
remoteControlAutoEligible: true
# every other session created after ~19:33 that day already shows false

For comparison, I checked every other local session record created in the same window
(interactive sessions and sub-agent/"spawn_task"-created sessions) — all of them correctly
reflect the toggle state at creation time (false after it was turned off). Only the
scheduled-task-created session is unconditionally true, which matches the separate-code-path
root cause already identified in this issue. Might be useful confirmation that the bug is scoped
specifically to scheduled-task/Routine session creation, not to session creation generally.

*(Edit: corrected an arithmetic error in the original timing claim — it said "off for ~40
minutes" when the gap is actually ~2h40m, and I don't have a precise timestamp for when the
toggle itself was flipped, only that it was already off by ~19:33 that day.)*