[DOCS] Contradictory `Bash(*)` vs `Bash` permission syntax between Settings and CI/CD guides
Documentation Type
Missing documentation (feature not documented)
Documentation Location
- Settings/IAM Reference: https://code.claude.com/docs/en/settings#permission-rule-syntax and https://code.claude.com/docs/en/iam#configuring-permissions * GitLab CI/CD Guide: https://code.claude.com/docs/en/gitlab-ci-cd#basic-gitlab-ci-yml-claude-api
Section/Topic
The Permission Rule Syntax section in Settings and the configuration examples provided in the GitLab CI/CD and GitHub Actions guides.
Current Documentation
In docs/en/iam (Configuring permissions):
"Note thatBash(*)does not match all Bash commands. UseBashwithout parentheses to match all uses."
In docs/en/settings (Permission rule syntax):
"Bash(*)does not match all Bash commands. The*wildcard only matches within the specifier context. To allow or deny all uses of a tool, use just the tool name:Bash, notBash(*)."
However, in docs/en/gitlab-ci-cd (Configuration examples):
The code snippet uses:
--allowedTools "Bash(*) Read(*) Edit(*) Write(*) mcp__gitlab"
What's Wrong or Missing?
There is a direct contradiction between the core permission documentation and the CI/CD integration examples.
The Settings documentation explicitly warns users not to use Bash(*) if they intend to match all commands, stating it will not work as a catch-all. However, the CI/CD guides (GitLab and GitHub Actions examples) specifically use Bash(*) in their CLI arguments to presumably allow all Bash commands for the automated job.
If the Settings documentation is correct, users copying the CI/CD examples will likely encounter permission failures because Bash(*) will not actually whitelist all Bash activity in their pipeline. If Bash(*) does work, the Settings documentation warning is incorrect.
This likely applies to Read(*) and Write(*) in the examples as well, as the Settings doc states: "To match all uses of a tool, use just the tool name without parentheses".
Suggested Improvement
Assuming the Settings/IAM documentation is the source of truth regarding permission syntax:
Update the code snippets in docs/en/gitlab-ci-cd and docs/en/github-actions to use the correct catch-all syntax.
Change this:--allowedTools "Bash(*) Read(*) Edit(*) Write(*) mcp__gitlab"
To this:--allowedTools "Bash Read Edit Write mcp__gitlab"
Impact
High - Prevents users from using a feature
Additional Context
The Bash(*) syntax implies matching arguments inside the parentheses. Since the asterisk matches "any sequence of characters," it technically might work for commands that have arguments, but might fail on commands with no arguments (or vice versa depending on internal regex implementation), which is likely why the Settings doc warns against it.
Ensuring the CI/CD examples use the most robust, error-free syntax is critical for automated pipelines where no user is present to handle a permission prompt failure.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗