Scheduled task execution appears to ignore CLAUDE_CONFIG_DIR, falls back to ~/.claude/scheduled-tasks/

Environment: CLAUDE_CONFIG_DIR set to a custom path (~/ClaudeCode) via .zshrc, confirmed active in interactive shell sessions. list_scheduled_tasks correctly reports each task's path under $CLAUDE_CONFIG_DIR/scheduled-tasks/.

What happened: A scheduled task (claude-code-github-backup, daily git-native backup) silently stopped running for ~110 hours (2026-09-30 23:40 to 2026-10-05 14:10 local), along with three other daily tasks (claude-code-github-backup-selfheal, daily-skill-watch, cowork-command-center-refresh) producing zero sessions for 3 consecutive days. All four self-reported success/normal operation throughout — no error was logged anywhere.

Root cause found: ~/.claude/scheduled-tasks/ — the default config directory, not the one set by CLAUDE_CONFIG_DIR — contained a separate, stale copy of these same task IDs' SKILL.md files, last touched before CLAUDE_CONFIG_DIR was set (2026-08-12). These stale copies pointed at a retired, pre-migration script path. Fix was to manually copy the current task definitions from $CLAUDE_CONFIG_DIR/scheduled-tasks/ into ~/.claude/scheduled-tasks/, which immediately restored correct execution.

Working theory, not confirmed: the scheduler's background execution process doesn't inherit CLAUDE_CONFIG_DIR from the interactive shell (likely because it runs as a detached/GUI process that doesn't source .zshrc), so it falls back to the hardcoded default ~/.claude location regardless of the env var. This means any task definition edited only in the CLAUDE_CONFIG_DIR location can silently drift out of sync with what actually executes, with no warning.

Ask: Can the scheduler's task-execution path either (a) respect CLAUDE_CONFIG_DIR consistently with the rest of the CLI, or (b) at minimum warn/error when a task ID exists in both locations with differing content, instead of silently executing a stale copy?