Current Behaviour

• Every Claude-provider agent run in Bitbucket Pipelines gets an auto-generated config/settings.json injected by the harness, which currently hardcodes:

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": ["Edit", "Write", "Monitor", "Skill", "Bash", "mcp__bitbucket-pipelines"]
  }
}

• Because "Bash" here is unscoped (not pattern-restricted like Bash(curl *)) and defaultMode is dontAsk, this pre-approves every Bash command for every Claude Pipelines agent regardless of what the customer configures in their own settings-pipelines.json (config.path) or on-ask in bitbucket-pipelines.yml.
• Neither allow restrictions nor defaultMode changes in the customer's own config can reduce this default; the only lever available is adding explicit deny rules (which win over allow regardless of layer), and customers must anticipate and enumerate every risky command pattern themselves (curl, wget, python, node, bash -c, etc.) since there are many POSIX-equivalent ways to achieve arbitrary code execution.
• This is because, in Claude, rules are evaluated in the order: deny, then ask, then allow. The first match in that order determines the outcome, and rule specificity doesn’t change the order.
• The first Allow wins regardless of if it's overridden later with a more specific Allow (ie user-defined allowlist in Claude config).

• A Deny at a later level still wins over previous Allows, however, due to the order precedence defined above (deny is highest in the order).

• Because the pipelines system base config sits at the top of the list, its allowlist takes precedence over any allowlist defined by the user.

Desired Behaviour

 1.  Allow the harness-injected default settings.json to be disabled/opted out of via an explicit config flag (e.g. permissions.disableDefaults: true), so customers can build permissions entirely from their own config without the injected Bash wildcard.
 2.  Scope the harness default Bash allow entry to only what's actually required for pipeline operation, rather than a blanket "Bash".
 3.  Provide a genuine "strict allowlist" / default-deny mode at the repo/pipeline level, where on-ask (or equivalent) gates all tool invocations not explicitly allowlisted — including ones introduced by harness defaults.

Current Workaround

Customers must proactively enumerate an explicit deny list (in .claude/settings-pipelines.json or via config.overrides.permissions.deny in bitbucket-pipelines.yml) covering all risky tool/command patterns, since deny overrides the harness's Bash allow regardless of layer.