Scheduled tasks created from an SSH workspace always fail with "failed to start scheduled task"

Environment

• Claude Code 2.1.177, desktop app on macOS
• Setup: desktop app runs on a local Mac; the session's workspace is a directory on a remote machine connected over SSH (remote is also macOS, Darwin 25.4.0)
• Scheduled tasks are stored on the local Mac under ~/.claude/scheduled-tasks/ (confirmed via the scheduled-tasks MCP tools)

Bug: scheduled tasks created from an SSH workspace can never run

Any scheduled task created from a session whose workspace is an SSH remote fails immediately with "failed to start scheduled task" — both on "Run now" and at its scheduled fire time. This happens even when the task's prompt is fully self-contained (explicitly instructed to do no file reads, no shell, no SSH — just print reminder text), so it isn't the prompt needing remote resources: the runner appears to pin the creating session's workspace and can't re-establish the SSH connection for a background run.

Repro

1. Open a desktop-app session whose workspace is a remote SSH directory.
2. From that session, create a one-time scheduled task (fireAt in the future). Prompt content irrelevant — a pure "print this reminder text" prompt reproduces it.
3. Click Run now on the task (or wait for the fire time).
4. ➜ "failed to start scheduled task". No further diagnostics surfaced.
5. Create an identical task from a local (non-SSH) session on the same Mac → "Run now" works first try.

Expected

Either (a) the scheduled run starts in a local/default workspace when the original workspace is an unreachable SSH remote — at minimum for prompts that don't need the workspace — or (b) task creation from an SSH workspace warns up front that scheduled runs won't be able to start, instead of accepting the task and failing later. A silent-forever-failing reminder is the worst case for exactly the "remind me next week" use these tasks exist for.

Secondary symptom noticed while diagnosing

The Scheduled/routines list in the sidebar rendered empty while an enabled task existed in the registry (list_scheduled_tasks returned it the whole time). The task reappeared in the UI only when an unrelated task-creation approval dialog forced a refresh. Looks like the list can go stale; worth a look in the same area.