Summary
The Claude engine auto-selects --permission-mode bypassPermissions
whenever the compiled tool set contains a bash wildcard
(pkg/workflow/claude_engine.go hasBashWildcardInTools). The network
egress firewall injects bash: ["*"], so enabling the firewall
implicitly disables --allowed-tools enforcement (see #28046, #28120).
There is no first-class config field for the permission mode. The only
override is appending a second --permission-mode <value> via
engine.args and relying on Claude Code honoring the last occurrence
of the flag — undocumented behavior that would silently regress to
bypassPermissions if gh-aw ever dedupes engine flags.
acceptEdits (gh-aw's non-wildcard default) does enforce
--allowed-tools, but its static bash filter rejects shell variable
expansion ("$VAR") and compound commands, so workflows that call e.g.
gh pr view "$PR_NUMBER" cannot use it. That leaves auto as the only
viable mode for such workflows, and it is only reachable via the
engine.args workaround.
Affected Area
pkg/workflow/claude_engine.go — hasBashWildcardInTools and
--permission-mode flag emission.
Reproduction
- Compile a workflow that enables the network egress firewall.
- Inspect the compiled lock file:
--permission-mode bypassPermissions
is emitted.
- Inspect the Claude Code session-init JSON in the run log:
"permissionMode": "bypassPermissions"; --allowed-tools has no
effect.
Expected Behavior
-
The permission mode is a first-class, validated config field, e.g.:
engine:
id: claude
permission-mode: auto # auto | acceptEdits | plan | bypassPermissions
The compiler emits exactly one --permission-mode flag and surfaces
the chosen value in the compiled lock file.
-
The presence of a bash wildcard in the tool set is not the sole
trigger for bypassPermissions. Enabling the network egress
firewall and keeping a strict --allowed-tools boundary are
independent choices.
Related
Summary
The Claude engine auto-selects
--permission-mode bypassPermissionswhenever the compiled tool set contains a bash wildcard
(
pkg/workflow/claude_engine.gohasBashWildcardInTools). The networkegress firewall injects
bash: ["*"], so enabling the firewallimplicitly disables
--allowed-toolsenforcement (see #28046, #28120).There is no first-class config field for the permission mode. The only
override is appending a second
--permission-mode <value>viaengine.argsand relying on Claude Code honoring the last occurrenceof the flag — undocumented behavior that would silently regress to
bypassPermissionsifgh-awever dedupes engine flags.acceptEdits(gh-aw's non-wildcard default) does enforce--allowed-tools, but its static bash filter rejects shell variableexpansion (
"$VAR") and compound commands, so workflows that call e.g.gh pr view "$PR_NUMBER"cannot use it. That leavesautoas the onlyviable mode for such workflows, and it is only reachable via the
engine.argsworkaround.Affected Area
pkg/workflow/claude_engine.go—hasBashWildcardInToolsand--permission-modeflag emission.Reproduction
--permission-mode bypassPermissionsis emitted.
"permissionMode": "bypassPermissions";--allowed-toolshas noeffect.
Expected Behavior
The permission mode is a first-class, validated config field, e.g.:
The compiler emits exactly one
--permission-modeflag and surfacesthe chosen value in the compiled lock file.
The presence of a bash wildcard in the tool set is not the sole
trigger for
bypassPermissions. Enabling the network egressfirewall and keeping a strict
--allowed-toolsboundary areindependent choices.
Related
bypassPermissionsmakes--allowed-toolsineffectivebypassPermissions+--allowed-toolssecurity boundary and add gateway-side enforcement #28120 — documentation + gateway-side enforcement follow-up