[BUG] Scheduled-task sessions stopped auto-connecting to Remote Control on 3 Sept — the "Connect new sessions" preference does not cover them

Confirming on macOS with the same timeline and the same evidence shape.

• macOS (Darwin 25.6.0), Claude Desktop 1.40609.1 → 1.44121.4 (updated 3 Sep 2026 08:55 BST) → 1.46388.2 → 1.46388.4 → 1.49585.0. CLI now 2.1.207 (bundled). "Connect new sessions to Remote Control" is ON; agentPushNotifEnabled and inputNeededNotifEnabled true.
• From ~/Library/Logs/Claude/main.log, scheduled spawns followed by Enabling remote control for session within 20 s:

| Date | App version | Scheduled spawns | Got Remote Control |
|---|---|---|---|
| 28 Aug – 2 Sep | 1.40609.x | 18 | 18 |
| 3 Sep, before the 08:55 update | 1.40609.1 | 3 | 3 |
| 4 Sep | 1.46388.2 | 6 | 0 |
| 7 Sep | 1.46388.2/.4 | 6 | 0 |
| 8 Sep | 1.46388.4 | 4 | 0 |
| 9 Sep | 1.49585.0 | 8 | 0 |

• Every PushNotification from a scheduled-task session since the update returns either Mobile push not sent (Remote Control inactive). or Not sent — this terminal is active, so your output here already reaches the user; a separate notification would be redundant. The latter is returned even with the screen locked and nobody at the machine (three controlled one-off runs on 9 Sep). Interactive sessions in the same app return Mobile push requested. and the phone receives them.
• Practical effect, same as above: scheduled routines that stall on a permission prompt are indistinguishable from routines that found nothing, because the "action required" push never leaves the Mac.

Matches the remoteControlPolicyCovers exclusion described in #92113. A per-user setting to include scheduled-task sessions in the auto-connect policy would restore the pre-3-Sep behaviour.

Cause, read out of the desktop bundle (Windows 10 19045, Claude Desktop 1.46388.4, bundled CLI 2.1.260).

In resources/app.asar the auto-enable policy is:

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

!e.scheduledTaskId excludes every session belonging to a scheduled task. Because maybeAutoEnableRemoteControl() returns at its first guard when this predicate is false, the [rcAutoEnable] verdict: enable=... source=... trigger=... line is never reached — so there is no verdict in main.log and no source explaining the refusal. That silence is why this looks like the engine dying rather than a policy exclusion.

The only remaining route is the || !!e.remoteControlUserRequested clause, which is set solely by the client-side /remote-control command (alias /rc) typed into that session.

"Run now" does not help either. The exclusion keys on the session having a scheduledTaskId, not on how it started, so a task with no cron and no fireAt — launched by hand from the sidebar — is excluded identically. Two examples from 8 Sep, both manual-trigger, both bridged only after the command was typed: session created 08:48:08 → bridged 09:48:17; created 10:55:06 → bridged 11:55:13.

Measured here, correlating every Enabling remote control for session line against the immediately preceding LocalSessions.sendMessage ... messageLength=15 (/remote-control is exactly 15 characters):

| window | bridges | automatic | typed by hand |
|---|---|---|---|
| 21–28 Aug | 86 | 83 | 3 |
| 28 Aug – 7 Sep | 72 | 59 | 13 |
| 7 Sep 18:30 – 8 Sep 12:00 | 13 | 0 | 13 |

[rcAutoEnable] verdict: lines with trigger=first_turn: 53 across 30 Aug – 2 Sep, then none.

Also worth flagging: typing /remote-control into a session with no active query logs [warn] Cannot toggle remote control for <id>: no active query and silently does nothing, so the workaround often takes two attempts.

If the exclusion is deliberate, the ask is narrower: say so in the setting's description, emit enable=false source=scheduled_task rather than returning before the log point, and offer an opt-in for users who own both ends.

Still present on Desktop 1.52386.6.0 (bundle built 13 Sep) with bundled CLI 2.1.270 — two app releases beyond the 1.49585.0 in the comment above, and unchanged in both code and behaviour.

The predicate is byte-for-byte identical in the current bundle:

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

Behaviour today (14 Sep), one Windows machine, "Connect new sessions to Remote Control" ON throughout:

• 14 scheduled-task sessions spawned between 02:00 and 13:46, including unattended overnight runs at 02:00, 04:12, 04:36, 06:55 and 07:01.
• 0 of the 14 auto-connected. No [rcAutoEnable] verdict line for any of them, as expected from the early return.
• The only three Enabling remote control for session lines in the entire day are source=user_intent trigger=cold_resume — sessions that had been bridged by hand on an earlier day re-attaching on resume. None of them is a newly spawned session being covered by the preference.

So the count of automatic connections for newly spawned scheduled sessions is still 0, now 12 days and several releases after 3 Sep.

One behaviour worth documenting for anyone else hitting this, since it is not obvious and it changes what the workaround is worth: remoteControlUserRequested persists on the session once set. A session bridged by hand once will re-bridge itself automatically on later resumes, logging source=user_intent. That is why a machine can show a handful of bridged sessions while still having nothing new connect — those are old sessions re-attaching, not the preference working.

Two consequences:

1. It does not help new sessions at all. Every newly spawned scheduled session still needs the command typed into it by hand, which is the actual cost being paid daily here.
2. It makes the regression easy to misdiagnose as partially working. Counting Enabling remote control lines alone suggests auto-connect is alive; separating source=user_intent (an old session resuming) from source=explicit_pref trigger=first_turn (the preference actually applying) is what shows the latter has not fired since 2 Sep.

Also confirming the earlier note about the no active query path, since it bears on how much the workaround is actually worth. Typing the command into a session with no live query logs Cannot toggle remote control for <id>: no active query and does nothing.

The !e.query branch in the bundle does contain an assignment setting remoteControlUserRequested, so it looks at first read as though the request is latched and will take effect on the session's next turn. It is not: that assignment sits behind a guard chain the plain user-typed command does not satisfy. Observed here on 8 Sep — a session warned no active query at 11:44:17, cold-resumed on a real message at 11:45:25 producing no source=user_intent verdict, and bridged only after the command was typed a second time at 11:45:28.

So nothing is deferred, and on a scheduled session that has already finished its turn the workaround fails silently on the first attempt.