[BUG] --add-dir is silently ignored when Claude Code is launched headless from Windows Task Scheduler

Environment

• Claude Code CLI 2.1.220 on Windows 11 Pro 10.0.26200
• Launch context: claude invoked headless (-p / piped prompt) by a Windows Task Scheduler task via a cmd wrapper; same behavior when the launch is a Python subprocess child of such a task
• Interactive and desktop-app-lineage sessions on the same machine honor the flag normally

Expected

Directories passed via --add-dir <path> become additional working directories — file tools can read them, exactly as in interactive sessions.

Actual

In Task-Scheduler-spawned sessions the flag is accepted (no error, no warning) but has no effect: reads under the added directory are refused as outside the allowed directories. The same invocation line run from an interactive terminal honors the flag.

Repro

1. Create a Task Scheduler task running claude -p "<prompt that lists a file under D:\some\dir>" --add-dir "D:\some\dir" (any directory outside the cwd).
2. Fire the task; the session reports the path is not accessible / requires permission.
3. Run the identical command in an interactive terminal: access is granted.

Impact

Headless automation cannot extend its directory surface per-invocation; the only workaround is permissions.additionalDirectories in user-level settings.json — which has its own defect in this launch context (single-slot, last-entry-wins; filed separately).

Notes

Probed live three times on 2026-07-29/30 with directory-listing probes inside the spawned sessions; behavior consistent across ~30-minute-separated runs.

Related (different asymmetries, may share a root cause): #37553 and #30064 (skills load from --add-dir but not additionalDirectories, interactive context), #52934 (settings/hooks not loaded from added dirs).