Desktop 1.44121.1 silently removed Remote Control auto-enable for scheduled-task sessions; please add an opt-in and a release note

Environment

• Claude desktop app (macOS, Code tab). Behavior changed at 1.44121.1; present on 1.44121.2, 1.44121.4, 1.46388.1, 1.46388.2.
• Claude Code CLI 2.1.258. macOS Darwin 25.3.0.
• ~/.claude/settings.json: "remoteControlAtStartup": true. Desktop preference ccRemoteControlDefaultEnabled: true. Neither changed.

What changed
Through desktop 1.40609.1, every session spawned for a local scheduled task (~/.claude/scheduled-tasks/*) auto-enabled Remote Control one to two seconds after spawn. The session showed up on the Claude mobile app with push notifications and could be steered from the phone. From 1.44121.1 onward, no scheduled-task session auto-enables. Interactive sessions still do, so the setting still works; scheduled-task sessions were carved out.

This looks deliberate, not a bug. In the current bundle (app.asar, 1.46388.2) the startup policy explicitly excludes scheduled-task sessions:

remoteControlPolicyCovers(e){return!!e.remoteControlAutoEligible&&!e.scheduledTaskId}

Around it is a full design: rcPolicyBridgeYieldsOnScheduledRun lets the idle-pause logic tear down a scheduled run even if a policy bridge is up, markScheduledRunContinued flips a run to a normal session only once a person sends it input, and the pause path logs "startup-policy bridge on a scheduled-task run yielded". The telemetry event desktop_ccd_session_pause_blocked_by_rc carries is_scheduled_task_session, which suggests the motive: auto-enabled bridges were keeping scheduled-task sessions alive and blocking pause.

Log evidence (~/Library/Logs/Claude/main1.log, main.log)
Each [CCDScheduledTasks] Spawning new session for scheduled task <name> was paired with the next [rcAutoEnable] verdict and Enabling remote control for session lines within 8 seconds.

09-02 09:09:34 monthly-report  spawn
09-02 09:09:35 [rcAutoEnable] verdict: enable=true source=explicit_pref trigger=first_turn
09-02 09:22:50 [updater] Version changed since last launch: 1.40609.1 → 1.44121.1
09-02 12:12:34 dashboard-refresh    spawn   (no rcAutoEnable verdict at all; policy never evaluated)
... every scheduled spawn through 09-04 07:11: no verdict, no bridge
09-04 07:11:12 preshift-am        spawn
09-04 07:11:25 toggleRemoteControl enable=true   <- user toggled by hand 13 s later

Counts: 48 of 48 scheduled spawns auto-enabled in the log covering 8/29 to 9/2 09:22. 0 of 53 did from 9/2 09:22 to 9/4.

Why this matters
Scheduled tasks plus Remote Control was the only zero-setup way to run an unattended workload on a local machine and supervise it from a phone. Removing it without a release note, a changelog entry, or a settings switch broke a workflow the product had been supporting for months. The routines docs and the Remote Control docs do not mention the change either.

Ask

1. A setting (settings.json key or desktop toggle) that opts scheduled-task sessions back into the startup Remote Control policy, with the idle-pause behavior of the operator's choosing.
2. A release note for 1.44121.1 describing the change.
3. If the intended replacement is cloud routines (the bundle also ships a scheduled-task-to-routine migration sweep, cowork_scheduled_tasks_auto_migrated), say so in the docs, and note that cloud runs cannot reach a local machine's files, Keychain, or local MCP servers.

Related

• #87777 (desktop Remote Control auto-enable only evaluated on first turn; idle teardown clears it), open.
• #70546 (programmatic Remote Control start), closed not-planned, so there is no supported workaround.