[DOCS] Permissions docs still say Bash commands always prompt despite read-only exceptions
Documentation Type
Incorrect/outdated documentation
Documentation Location
https://code.claude.com/docs/en/permissions
Section/Topic
"Permission system" and Bash command approval behavior
Current Documentation
The docs currently say:
| Tool type | Example | Approval required | "Yes, don't ask again" behavior | | :---------------- | :--------------- | :---------------- | :-------------------------------------------- | | Read-only | File reads, Grep | No | N/A | | Bash commands | Shell execution | Yes | Permanently per project directory and command |
The permission modes page also says:
When Claude wants to edit a file, run a shell command, or make a network request, it pauses and asks you to approve the action.
And the headless docs say:
acceptEditslets Claude write files without prompting and also auto-approves common filesystem commands such asmkdir,touch,mv, andcp. Other shell commands and network requests still need an--allowedToolsentry or apermissions.allowrule, otherwise the run aborts when one is attempted:
What's Wrong or Missing?
Changelog v2.1.111 says: "Read-only bash commands with glob patterns (e.g. ls *.ts) and commands starting with cd <project-dir> && no longer trigger a permission prompt".
That behavior is not reflected in the current docs. The current permission docs still describe Bash approval as a blanket rule, and the headless docs still say non-listed shell commands prompt or abort unless explicitly allowed.
As a result, the docs are outdated about the current Bash permission flow for at least two user-visible cases:
- read-only Bash commands that include shell glob expansion
- commands prefixed with
cd <project-dir> &&that stay within the project directory
Suggested Improvement
Update the permissions documentation to describe the read-only Bash exceptions introduced in v2.1.111.
Suggested additions:
- Add a short note under the Bash permission rules explaining that some read-only Bash commands are auto-approved and no longer prompt.
- Include explicit examples such as
ls *.tsandcd <project-dir> && git status. - Clarify the boundary conditions: which read-only patterns are exempt, and which commands still prompt (for example writes, protected paths, networked actions, or commands outside the project/additional directories).
- Cross-reference the same behavior from
permission-modes,tools-reference, andheadlessso those pages do not continue to imply that all Bash commands always require explicit approval.
Impact
Medium - Makes feature difficult to understand
Additional Context
Affected Pages:
| Page | Context |
|------|---------|
| https://code.claude.com/docs/en/permissions | Permission system table currently says Bash commands require approval |
| https://code.claude.com/docs/en/permission-modes | Overview says shell commands pause for approval without mentioning these read-only exceptions |
| https://code.claude.com/docs/en/tools-reference | Bash is listed as requiring permission, with no note about these read-only cases |
| https://code.claude.com/docs/en/security | Security overview says bash commands require approval before execution |
| https://code.claude.com/docs/en/headless | Says other shell commands still need --allowedTools or permission rules |
Total scope: 5 pages affected
Source: Changelog v2.1.111
Exact changelog entry: Read-only bash commands with glob patterns (e.g. ls *.ts) and commands starting with cd <project-dir> && no longer trigger a permission prompt
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗