Claude engine: bypassPermissions mode makes --allowed-tools ineffective — gateway tool set is the sole agent tool boundary

[szabta89]

Summary

The gh-aw Claude engine unconditionally starts Claude Code with --permission-mode bypassPermissions (claude_engine.go:161). In this mode, Claude Code ignores the --allowed-tools flag entirely, making all tools advertised by the MCP gateway available to the agent regardless of the workflow's declared tool configuration. The --allowed-tools flag — documented as the primary tool-restriction control — therefore provides no security enforcement for the Claude engine. Separately, awmg-github v0.2.19 added get_teams and get_team_members to its tool set without a coordinated update to the gh-aw v0.68.3 compiler's tool-to-toolset mapping, but this synchronization gap is a secondary concern: even when the mapping is complete, bypassPermissions nullifies the allowlist anyway.

Affected Area

Claude engine tool-restriction boundary (pkg/workflow/claude_engine.go). The --allowed-tools flag is the stated security control for limiting which MCP tools an agent may call. bypassPermissions makes this control ineffective.

Reproduction Outline

1. Compile a gh-aw workflow targeting the Claude engine with a restricted tool configuration (e.g., github-readonly profile that does not include get_teams or get_team_members).
2. Run the compiled workflow; inspect /tmp/gh-aw/agent-stdio.log for the Claude Code entrypoint command — confirm --allowed-tools is present and omits mcp__github__get_teams and mcp__github__get_team_members.
3. Inspect the session-init JSON line in the same log; observe "permissionMode": "bypassPermissions" and both excluded tools present in the "tools" array.
4. Using the bearer token from /tmp/gh-aw/mcp-config/mcp-servers.json (readable with Bash), send a direct tools/call for get_teams to the MCP gateway.
5. Observe the response is a GitHub API error (not a gateway-level rejection) — the tool executed.

Observed Behavior

Claude Code is started with --permission-mode bypassPermissions and --allowed-tools <list>. The agent's session-init tool list contains all tools advertised by awmg-github v0.2.19 (22 tools), including get_team_members and get_teams which are absent from the allowlist. Direct tools/call for these tools succeeds (returns a GitHub API response, not a gateway rejection).

Expected Behavior

Either: (1) Claude Code respects --allowed-tools and tools absent from the allowlist are unavailable to the agent and rejected at call time; or (2) if bypassPermissions is intentional and --allowed-tools cannot be relied on as a security control in automated mode, this must be clearly documented and gateway-side per-session tool enforcement must serve as the effective control.

Security Relevance

The --allowed-tools flag is the documented mechanism by which workflow authors limit agent capabilities to only the tools declared in their workflow markdown. If this control is silently bypassed by bypassPermissions, agents can call any tool the gateway exposes — including tools from toolsets the workflow author never configured. This widens the effective attack surface beyond the workflow's stated permission model and could allow an agent (or prompt injection in agent input) to invoke sensitive tools the workflow owner did not intend to enable.

Additional Context

If bypassPermissions is by design (e.g., required for non-interactive operation), this assumption should be documented explicitly alongside the security model. The AGENTS.md instructions and gh-aw documentation currently list tool allowlists as a key security feature without acknowledging that the allowlist has no effect in bypassPermissions mode. Clear documentation of this trade-off would help workflow authors understand what controls are actually enforced.

Versions confirmed affected: gh-aw v0.68.3, awmg-github v0.2.19, Claude Code 2.1.98.

Original finding: https://github.com/githubnext/gh-aw-security/issues/1889

Generated by File Issue · ● 252.9K · ◷