Headless -p: additionalDirectories grants access but isn't listed in the session's environment context

Summary

In headless mode (claude -p), a directory granted via permissions.additionalDirectories in the project's .claude/settings.json is fully accessible to tools (Read/Glob/Grep succeed, permission_denials is empty) but is not listed in the system context's # Environment section — there is no "Additional working directories" entry at all. The same project on a machine where it has been used interactively lists the directory as expected.

Reproduction (observed on 2.1.198, Linux, GitHub Actions ubuntu runner)

1. Fresh environment (no prior ~/.claude.json state). Project .claude/settings.json:

``json
{ "permissions": { "additionalDirectories": ["../sibling-repo"] } }
``

1. Ensure ../sibling-repo exists on disk.
2. claude -p "Without using any tools: quote the section of your system context that lists the primary working directory and any additional working directories." --allowedTools ""

Observed: only Primary working directory: … is listed; no additional-working-directories line. Yet in the same environment, claude -p "Read ../sibling-repo/README.md" --allowedTools "Read" succeeds with permission_denials: [].

Expected: the granted directory appears in the environment listing, as it does in sessions on machines with prior interactive use of the project.

Why it matters

The model trusts its environment context. In our CI pipeline the model repeatedly concluded the sibling directory "isn't present in this environment" and skipped the work that needed it — without attempting a read that would have succeeded, because project docs (reasonably) told it to check the session's working-directory listing. Access being granted while the context says otherwise is a confusing split-brain.

Workaround

Passing --add-dir ../sibling-repo on the CLI both grants access and surfaces the directory in the environment listing, so we use that in CI. It would be nice if the settings-based grant behaved the same.