Cowork (cloud): routine sandbox Bash commands keep stopping for "Allow once" approval mid-task, despite user granting blanket permission
Surface: Claude Cowork on claude.ai, cloud session (web browser), model Opus 5.5.
What happens: In a long working session, ordinary Bash calls inside the session's own sandbox scratch directory (building a .docx with node, rendering a PDF with LibreOffice, running sed/python3 on local scratch files) intermittently stop the task and show a "Claude wants to use Running command — Deny / Allow once" card. Earlier, identical commands in the same session ran without any prompt. The prompt appears to be triggered by long or multi-line commands (heredocs, && chains), not by what the command does.
Why it is a bug: The user has explicitly told Claude, in the conversation and in their saved preferences, that it has permission to do whatever the task needs. Nothing touches their machine or accounts; it is scratch work in an ephemeral cloud container. Every prompt blocks the whole task until the user clicks, so an unattended task silently stalls and an attended one becomes a stream of clicks. There is no "always allow for this session" option on the card, only "Allow once".
Expected:
- Commands that only touch the session's own sandbox should not require approval, or
- the approval card should offer "Always allow in this session" / "Allow all Bash", and
- the user's chosen permission level should be applied consistently to every command in the session, not re-evaluated per command in a way that makes approval appear random.
Reporter's words: "You have my permission to do whatever you need to do to accomplish what I ask. Why do you need to keep pausing yourself and asking me to press buttons?"
Screenshots show the card blocking two consecutive build commands (a python3 heredoc and a sed … && node … && soffice … chain) in session [id removed], 24–25 Sep 2026.