[BUG] Desktop 1.44121.4+ never auto-enables Remote Control for scheduled-task sessions (regression from 1.40609.0)

Confirming the same regression on macOS (Darwin 25.5.0, Apple Silicon iMac), so it is not Windows-specific.

Setup

• Claude Desktop 1.40609.1 (good) → 1.44121.1 installed 2026-09-03 00:59 JST (bad); still broken on 1.44121.2, 1.44121.4, 1.46388.1–1.46388.4.
• Desktop-bundled CLI 2.1.255 → 2.1.258 during the window (the CLI version does not correlate with the break; the Desktop version does).
• ~/.claude/settings.json has "remoteControlAtStartup": true. Max plan.
• 6–13 local scheduled tasks fire per day (daily morning/noon/evening content routines, nightly archive, weekly reports), so there is a large sample.

Evidence from ~/Library/Logs/Claude/main*.log (parsed every Spawning new session for scheduled task … line and checked whether the spawned local_* session logged Enabling remote control within 120 s):

| day | scheduled sessions auto-bridged |
|---|---|
| 2026-07-27 … 2026-09-02 (every day) | ~100% (e.g. 09-01: 6/6, 09-02: 4/4) |
| 2026-09-03 | 0/6 |
| 2026-09-04 | 0/6 |
| 2026-09-05 | 0/6 |

The very first scheduled run after the 1.44121.1 install (02:03 JST on 09-03, a nightly archive task) was already not bridged. User-opened sessions kept auto-bridging normally throughout (12–15 Enabling remote control events/day on 09-03…09-05).

Two related observations that may help whoever picks this up:

1. Toggling Remote Control manually on a scheduled-task session does work while its query is alive, and the app then logs Skipping pause for session … - remote control is active (explicit bridge, scheduled-task session). So the plumbing is intact; only the auto-enable path excludes these sessions, consistent with the !e.scheduledTaskId term identified above.
2. Once a scheduled session has been idle-paused (15 min), the manual toggle fails silently with Cannot toggle remote control for local_…: no active query. For a morning routine that finishes at 07:45 this means the user cannot attach from a phone later in the day unless they first send a message to wake the session. A "wake then bridge" fallback in the toggle would make the workaround discoverable.

Impact for us: a daily 07:00 routine that ends in an approval prompt used to be answerable from the phone; since 09-03 it never appears on mobile or claude.ai/code.

Same regression here (Windows 11, Desktop 1.44121.4, bundled CLI 2.1.258, Max plan). Logs on this machine: every scheduled-task session auto-enabled Remote Control on the previous build (36 of 36 between 8/31 and 9/3), and none have since the update (0 of 22 from 9/4 to 9/6), while interactive sessions still connect on their first turn. Confirmed the same remoteControlPolicyCovers / scheduledTaskId gate in the shipped bundle.

Please restore the previous behavior, or at least make it an opt-in as #92113 asks. My workflow depends on it: a morning briefing and mail/Teams checks run as scheduled tasks and I read them and continue the conversation from the phone. The only session type I cannot open by hand is exactly the one now excluded. Typing /remote-control into a scheduled session manually still connects it, so the capability is intact; only the automatic path was removed.

One more request while here: sessions started with claude --remote-control get random names like tkm-002-r04-binary-puddle, with no way to set a title from the command line. A --name option (as claude remote-control already has) would make several such sessions on a phone distinguishable.

Confirming on a second machine, and extending to a newer build.

Windows 11 Enterprise 10.0.26100, Desktop 1.49585.0 (commit 41ad1dff, built 2026-09-08), bundled CLI 2.1.260, remoteControlAtStartup: true in user settings throughout. Same remoteControlPolicyCovers(e){return!!e.remoteControlAutoEligible&&!e.scheduledTaskId} is present verbatim in 1.46388.4 and 1.49585.0 — so the exclusion has now shipped in three consecutive builds.

Log signature, for anyone confirming from main.log rather than session files: before the 1.40609.1 → 1.44121.4 stealth update (2026-09-03 16:27 local) every scheduled spawn logged [rcAutoEnable] verdict: enable=true source=explicit_settings trigger=first_turn ~1s after Starting local session, then Enabling remote control for session … and bridge_state: "connected". After it, scheduled spawns log the session start and then nothing about Remote Control at all — no verdict, no warning — consistent with maybeAutoEnableRemoteControl returning before the resolver runs. Counts on this machine: 54 of 54 sessions auto-enabled before the update; 0 of 34 since (all 34 were scheduled-task spawns across three different tasks). The two manual sessions on 2026-09-02 auto-enabled normally.

Impact here is the same as the OP's: unattended daily routines can no longer push to the phone (PushNotification → "Mobile push not sent (Remote Control inactive)") or be followed from mobile without someone at the PC toggling each run by hand. I'm travelling from 21 Sep with these tasks running unattended, so a per-task or user-tier opt-in — or simply honouring remoteControlAtStartup for scheduledTaskId sessions as 1.40609 did — would be very welcome.

I filed a duplicate of this (#92972) before finding this issue — wanted to add an independent confirmation with a slightly different data point.

My setup: Claude Desktop app on Windows 11, two production scheduled tasks (one recurring cron every 30min in a daily window, one recurring daily). Both kept executing successfully (lastRunAt in list_scheduled_tasks updated every day through 2026-09-08), but the last time either one produced a visible session in the mobile app's Remote Control session list was around 2026-09-03/04. After that, zero new sessions ever appeared on mobile for these tasks, and no push notifications were delivered — even though the tasks themselves never stopped running.

I also reproduced this cleanly with a one-off diagnostic scheduled task (fireAt a few minutes in the future, prompt just calls PushNotification): task executes (lastRunAt updates), but no session and no push, every time.

Confirmed this persists after updating Claude Code from 2.1.198 → 2.1.266 and restarting the Desktop app, with "Connect new sessions to Remote Control" already enabled in settings — so it's not a client-side config/version issue on my end, consistent with the root cause described above (the scheduledTaskId exclusion).

This lines up with the ~9/3-9/4 regression window others have noted here and in #78229.

Confirming on a further build, and adding how this interacts with the Dispatch lock in #91745 / #92976.

Windows 11 Pro (26200), MSIX. Desktop 1.49585.0 running; 1.52386.0 installed and pending restart, and its app.asar carries the same remoteControlPolicyCovers(e){return!!e.remoteControlAutoEligible&&!e.scheduledTaskId}. Bundled CLI 2.1.266. ccRemoteControlDefaultEnabled: true. Four scheduled tasks (cron, every 1-2 h through the day). main.log 6-11 Sept: 0 of ~75 scheduled spawns logged any [rcAutoEnable] line; every interactive session in the same folder logged verdict: enable=true source=explicit_pref trigger=first_turn and connected within 3 s. Last good day on this machine was 2 Sept (1.40609 / 2.1.255), same as the reports above. (Same account as the 3 Sept comment on #91839.)

Interaction with the Dispatch exclusiveCwd refusal: a scheduled session that is never bridged is also never isVisibleToRemoteDispatch (dispatchParentOrigin !== "local"), so when a scheduled run is the session holding the folder, Dispatch's CwdInUseError comes back without a session id and the orchestrator cannot route a follow-up to it. From the phone the user can neither see the run nor start anything else in that folder until the run's process pauses (15 min after its last turn). On this machine the 9 Sept 13:10 refusal was exactly that: the blocker was a scheduled-task run spawned at 13:09:55. The two regressions from the same update compound: the session you cannot see is the one that locks you out.

+1 to honouring the "connect new sessions" preference for scheduled sessions as 1.40609 did, or a per-task opt-in, and to logging the exclusion instead of returning before the verdict line.

Confirming the same:
It worked on 9/2 and then hasn't from 9/3 onward. The latest 2.1.272 claude-code with Desktop app "Claude 2.110.0 (dfb2ba) 2026-09-15T05:50:55.000Z" still has the issue.
It appears set_remote_control is in the --disallowedTools that the desktop app uses for its internal claude-code tool which in this case is 2.1.271 at this moment.

Still present in Desktop 1.52386.3, which is newer than every version listed in this thread, so the exclusion has survived at least four releases since 1.44121.4. The line is unchanged in that build:

remoteControlPolicyCovers(e){ return !!e.remoteControlAutoEligible && !e.scheduledTaskId }
shouldEvaluateRemoteControlPolicy(e){
  return (this.remoteControlPolicyCovers(e) || !!e.remoteControlUserRequested)
    && !e.remoteControlEnabled && !e.remoteControlUserToggled && !e.remoteControlAutoInFlight
}

On a machine with 20 enabled scheduled tasks, every automatic bridge attempt fails and the only sessions carrying a bridgeSessionIds value are ones toggled by hand in the Desktop UI. Confirming the silent-return point others have raised: there is no [rcAutoEnable] verdict: line for these sessions at all, so from the logs a refusal is indistinguishable from the pass never running.

Two things that look like workarounds and are not, in case they save anyone time:

1. remoteControlAtStartup: true in settings.json does nothing here. It is a CLI setting for interactive sessions; a Desktop-hosted scheduled session runs the CLI in SDK mode with the Desktop owning the bridge, so it is inert.
2. Sending /remote-control into a live scheduled session from another session does not work. The Desktop does intercept a message beginning /remote-control inside its own sendMessage, ahead of any session-type test, so this looks like it should bypass the exclusion. But a cross-session message is wrapped as <cross-session-message from=...> before it arrives, so the match never fires and the text lands in the transcript, where the receiving session replies that it cannot run slash commands from messages.

A workaround that does work. The CLI will bridge a session on request; it just declines when it does not believe it is interactive. claude --remote-control invoked from a scheduler has no TTY and silently degrades to an ordinary non-interactive run with no bridge. Give it a pty and the bridge comes up normally:

import pty
pty.spawn(["claude", "--remote-control", "--name", ROUTINE,
           "--permission-mode", "auto", PROMPT])

That session appears in the mobile app and on claude.ai/code, named, with full local tool access. So a scheduled routine can be run from launchd/cron this way instead of the Desktop scheduler, at the cost of giving up the Desktop's scheduling UI, its missed-run handling and its wake-from-sleep timer.

That the workaround is "do not use the built-in scheduler" is the argument for making this a setting rather than a hard-coded exclusion. The sessions that fire unattended are precisely the ones a user cannot reach any other way.

I posted the same comment in another related issue (#92976 ), with 50% of my productivity killed because of this bug for days, and with Claude not being able to find a workaround, I can't wait for Anthropic, I'm not paying 20x max plan for this. So I found a solution that works : Codex. Moved. Done.

Confirming, still broken as of today (2026-09-26) on Windows 11, Claude Desktop, CLI 2.1.283 (newer than every build cited above).

Two local scheduled tasks (routines): one firing every 13 min, one 6x/day. Sampled their spawned sessions from 2026-09-17 through today via the session API rather than log-scraping: every session carrying a scheduledTaskId reports remoteControlState "off" (remoteControlActive false), zero exceptions across dozens of runs. Every manually-started session in the same window reports "on". "Connect new sessions to Remote Control" has been on throughout, so this isn't a settings issue on affected machines.

Matches the remoteControlPolicyCovers(e) { ... && !e.scheduledTaskId } exclusion identified above.

Worth noting for impact: on mobile there's no independent view of these sessions at all. The Claude mobile app's Code tab only surfaces Cloud sessions, Projects, Remote Control, and Dispatch (per https://code.claude.com/docs/en/mobile.md), so a local scheduled-task session is invisible on mobile entirely until it's bridged, not just missing a Remote Control badge. The Desktop app's own Routines sidebar section (recently renamed from Scheduled) is unaffected here, both tasks and their run history list correctly there. This is purely the auto-bridge-to-Remote-Control path that's broken.