Scheduled tasks silently gray out "Run now" when SKILL.md uses CRLF line endings

Environment

• App: Claude desktop, version 1.7196.0.0 (Windows MSIX build, Claude_pzs8sxrjxfjjc)
• OS: Windows 11 Pro 26200
• Feature affected: Claude Code scheduled tasks (cron-driven local agents)

Summary

When a scheduled task's SKILL.md file uses Windows CRLF (\r\n) line endings in its YAML frontmatter, the desktop app's frontmatter parser fails silently. The task still executes correctly on its cron tick (the cron scheduler tolerates CRLF), but the UI:

1. Grays out the "Run now" button indefinitely (even after successful scheduled runs).
2. Shows a blank name and description in the task's edit dialog.
3. Surfaces a generic, misattributed error like "Scheduled task 'X' was skipped. The folder is not trusted." on an unrelated task's row (cross-row error bleed in the task list).

The user has no actionable signal pointing at the line endings. Diagnosis took ~2 days because the cron path still worked, the task SKILL.md looked valid in any text viewer, and the only log signal ([ScheduledTasks] Failed to parse task file: no frontmatter delimiters found) is generic and doesn't name the file.

Steps to reproduce

1. On Windows, create a scheduled task via the app, pointing at a SKILL.md file.
2. Open that SKILL.md in Notepad (or any editor defaulting to CRLF) and save it — even without changing content. The file is now CRLF.
3. Restart the app.
4. Observe: the task's "Run now" button is grayed; clicking "Edit" shows blank name/description.

Repro confirmed by converting the file back to LF (\r\n → \n) — the gray-out clears on next restart.

Expected behavior

The YAML frontmatter parser should accept both ---\n and ---\r\n as valid delimiters. The Claude scheduler and the skill loader both already tolerate CRLF (skills with CRLF frontmatter load fine and tasks with CRLF frontmatter run on cron). Only the task-editor / Run-now UI parser is strict.

Actual behavior

• Parser logs [ScheduledTasks] Failed to parse task file: no frontmatter delimiters found to main.log. No file path included.
• Task metadata loads as empty.
• "Run now" stays disabled.
• Recent error from a different task bleeds into the failing task's UI row.

Diagnostic evidence

Hex dump of a broken SKILL.md (before fix):

00000000: 2d2d 2d0d 0a6e 616d 653a 2064 6169 6c79  ---..name: daily
00000010: 2d62 7269 6566 0d0a 6465 7363 7269 7074  -brief..descript

Same file after \r\n → \n conversion:

00000000: 2d2d 2d0a 6e61 6d65 3a20 6461 696c 792d  ---.name: daily-
00000010: 6272 6965 660a 6465 7363 7269 7074 696f  brief.descriptio

In my case, 3 of 7 registered scheduled tasks were affected. Their cron runs continued working overnight while their UI controls were locked. The dirty files had been CRLF for weeks; the gray-out only started after a recent app update tightened the parser.

Suggested fixes (any of these would resolve the user-facing pain)

1. Accept \r\n in the frontmatter delimiter regex. One-line fix; matches how other parsers in the same app already behave.
2. Log the failing file path when emitting [ScheduledTasks] Failed to parse task file. Currently the warning is unactionable.
3. Surface a visible error in the task row ("Could not parse task file — see logs") instead of silently graying "Run now" with no explanation.
4. Don't cross-attribute errors between task rows (the "X was skipped" message appearing on task Y's row is independently confusing).

Workaround for other Windows users

Convert affected files in place:

$p = "$env:USERPROFILE\.claude\scheduled-tasks\<task>\SKILL.md"
[IO.File]::WriteAllText($p, [IO.File]::ReadAllText($p).Replace("`r`n","`n"))

Or in Python: open(p,'wb').write(open(p,'rb').read().replace(b'\r\n', b'\n')).