Routine card's folder picker does not rewrite the task's stored cwd — the routine stays bound to a deleted directory and fails silently

Environment

• Claude Code 2.1.232 (auto-updated from 2.1.229 the day before)
• Claude Desktop 1.30096.1
• macOS (Darwin 25.6.0), Apple Silicon
• UI language: Japanese

Symptom

I moved a repository (~/foo -> ~/projects/foo) and deleted the old path. The routine card now
shows:

「作業フォルダが存在しません。続けるには別のフォルダを選択してください」
("The working folder does not exist. Select another folder to continue.")

Selecting the new folder in that picker has no observable effect. The card keeps showing the same
error across app restarts.

Root cause (located)

Each routine's working directory is persisted as a per-task cwd field in:

~/Library/Application Support/Claude/claude-code-sessions/<workspaceId>/<projectId>/scheduled-tasks.json

Task record keys: id, cwd, cronExpression, enabled, createdAt, lastRunAt,
lastScheduledFor, filePath, fireAt, approvedPermissions, notifySessionId.

After using the folder picker, the persisted cwd is unchanged — still the deleted path.
Nothing else reachable to me changes it either:

• editing the task's SKILL.md does not affect cwd (that is a separate filePath field)
• the update_scheduled_task MCP tool exposes no cwd parameter
• create_scheduled_task exposes no cwd parameter either — cwd appears to be captured

implicitly from the creating session's working directory

Control experiment (two routines, same app, same store)

| routine | action taken | persisted cwd | lastRunAt |
|---|---|---|---|
| Routine A | deleted and re-created from a session in the new directory | ~/projects/foo (correct) | absent (proves re-creation) |
| Routine B | folder picker used on the card | ~/foo (still the deleted path) | retained from the previous run |

Delete->create is the only operation that rebinds cwd. The picker does not.

Impact — worse than a cosmetic card error

The same stale cwd also broke the routine's execution, and the failure left no trace anywhere I
look:

• the routine fired on schedule and lastRunAt advanced normally
• it produced no output, no notification, no log entry, and no error surfaced beyond the card message
• two consecutive daily runs were lost this way, and I noticed only two days later by manually

checking for missing output files

A routine that silently does nothing while reporting a fresh lastRunAt is indistinguishable from a
routine that ran successfully.

Steps to reproduce

1. Create a routine from a session whose working directory is /tmp/repro-old.
2. Let it run once, so lastRunAt is populated.
3. mv /tmp/repro-old /tmp/repro-new — the old path must no longer exist.
4. Open the routine's card. The "working folder does not exist" message appears.
5. Use the picker to select /tmp/repro-new.
6. Inspect scheduled-tasks.json: the task's cwd is still /tmp/repro-old.
7. Wait for the next scheduled fire: lastRunAt advances, no work is performed, nothing is reported.

Requests

1. Make the card's folder picker actually write the task's cwd. This is the primary bug.
2. Expose cwd on update_scheduled_task so the binding can be repaired without delete->create.

Delete also discards approvedPermissions, which forces a manual "Run now" re-approval before
the next unattended run — an easy trap to miss.

1. Surface routine run failures. A run that fails before doing any work should not advance

lastRunAt silently. A visible failure state — or simply not advancing lastRunAt — would have
made this detectable on day one instead of day three.

Possibly related

• #56688 (closed as duplicate) — selected working directory not applied
• #71837 (open, marked stale, labeled platform:windows) — "working directory no longer exists"

with no UI option to change the root directory

Neither describes the persisted-cwd mechanism or the silent-failure consequence above.