[BUG] Headless/agent Bash session hard-blocks all filesystem access outside primary working directory (regression — same prompt worked previously)

Summary

A Claude Code session running headlessly inside a single project repo (/home/thanasis/Programming/sg/plugins/pa) can no longer read, write, or execute against ANY path outside that one working directory — not other project trees, not even /tmp. Every Bash invocation touching an external path is denied immediately; no interactive approval prompt ever surfaces for the user to answer. The same task, with almost the same prompt, succeeded in a prior session (last quarter's run of this exact workflow read/wrote files under ~/Desktop/Atlantis/... without issue).

Repro

Session cwd: /home/thanasis/Programming/sg/plugins/pa (a git repo).

1. ls -la "/home/thanasis/Desktop/Atlantis/5.Strategy/2026/presentation/" →

ls in '...' was blocked. For security, Claude Code may only list files in the allowed working directories for this session: '/home/thanasis/Programming/sg/plugins/pa'.

1. find "/home/thanasis/Desktop/Atlantis" -iname "*roadmap*" → same "blocked" message.
2. cp "/home/thanasis/Desktop/Atlantis/.../33-S3-Sibyl-Devs_Q2.pptx" /tmp/s3-q2-source.pptx →

cp in '...' needs approval. The path is outside the working directories for this session ('/home/thanasis/Programming/sg/plugins/pa'). Allowing runs the command as written.

1. echo hello > /tmp/fofi-test.txt (plain /tmp, not another project) →

Output redirection to '/tmp/fofi-test.txt' needs approval. The path is outside the working directories for this session ('/home/thanasis/Programming/sg/plugins/pa'). Allowing runs the command as written.

1. python3 -c "<open a Desktop file>" → This command requires approval — call fails, no prompt shown.

None of these ever produced an interactive approval the user could answer — every attempt (ls/find/cp/echo/python3) returned a synchronous denial in the same turn, despite the user being actively present in the conversation and never having denied anything.

Inconsistent with the Read tool

In the same session, the Read tool successfully located and opened the same out-of-workdir file (.../33-S3-Sibyl-Devs_Q2.pptx) — it returned a "cannot read binary .pptx file" error, not a permission/path error. So Read is NOT scoped to the single working directory, while Bash is hard-scoped with no approval path. Two tools, two different security models, same session.

Impact

Any task spanning multiple directories (read source files from one location, write a deliverable to another — e.g. this user's recurring "build the quarterly strategy deck from Desktop files" workflow) is now impossible in this session type, despite having worked with essentially the same prompt last quarter.

Expected

Either (a) an interactive approval prompt should actually surface to the user for out-of-workdir Bash commands, per documented permission-mode behavior, or (b) if this is intentional hard-sandboxing for headless/background sessions, it should be discoverable/documented so the assistant can explain why a previously-working workflow now fails, plus a supported way to add directories to the allowed set for such a session. Related but distinct: #92582, #94560.

Environment

• Claude Code CLI, headless/agent session, project repo sg/plugins/pa
• Platform: Linux
• Denial messages reference "allowed working directories for this session"