[BUG] permissions.additionalDirectories acts as a single slot — only the last array entry is honored (headless/Task-Scheduler sessions)

Environment

• Claude Code CLI 2.1.220 on Windows 11 Pro 10.0.26200
• Observed in headless sessions spawned by Windows Task Scheduler; additionalDirectories set in user-level ~/.claude/settings.json

Expected

Per the settings documentation, permissions merge across scopes and additionalDirectories is an array — every listed directory should be accessible.

Actual

Only the last entry of the array is honored. With two entries, reads under the first are refused while reads under the second succeed; swapping the order flips which one works. Effectively a single-slot setting.

Repro

1. In user-level settings.json set "additionalDirectories": ["C:\\dirA", "C:\\dirB"].
2. Fire a Task-Scheduler headless session that lists a file under each.
3. dirB works, dirA is refused. Reverse the array; the failure follows the first position.

Impact

Contradicts the documented merge behavior and silently narrows automation's directory surface; combined with --add-dir being ignored in the same launch context (filed separately), headless sessions have exactly one extra-directory slot.

Notes

Live-probed 2026-07-29/30. Our local mitigation was consolidating all needed content under one directory and reducing the array to that single entry.

Related: #14097 reports the /add-dir slash command persisting only the last directory to settings (write-layer overwrite, Windows). This report is the read/enforcement layer honoring only the last entry of a correctly-written array in headless sessions — distinct layers, same visible symptom class.