Summary

After PR #1002 ("Harden tag mode tool permissions against prompt injection", merged March 12, 2026), project-level .claude/settings.json permissions.allow entries are no longer respected in tag mode.

The hardcoded --allowedTools list in src/modes/tag/index.ts combined with headless acceptEdits mode means any tool not in that hardcoded list falls to "ask" → no prompt handler → denied. Project settings are loaded (settingSources confirms ["user", "project", "local"]), but effectively ignored.

Example

Given a project .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(pnpm test:*)",
      "Bash(pnpm fix:*)",
      "Bash(node:*)"
    ]
  }
}

Any @claude task that requires running tests hits repeated permission denials, even though these tools are explicitly allowed in the project settings.

Root Cause

PR #1002 changed src/modes/tag/index.ts to:

claudeArgs += ` --permission-mode acceptEdits --allowedTools "${tagModeTools.join(",")}"`;

Where tagModeTools is a hardcoded list of read tools + git operations + GitHub MCP tools. In headless acceptEdits mode, anything not in --allowedTools is denied with no fallback.

Previously Working

Issue #189 was closed in June 2025 with the reporter confirming that .claude/settings.json permissions were being reflected in the action without any special configuration. This confirms the behavior worked before the hardening changes.

Docs Conflict

From Claude Code Settings:

Array settings merge across scopes. When the same array-valued setting (such as permissions.allow) appears in multiple scopes, the arrays are concatenated and deduplicated, not replaced.

The current behavior contradicts this — CLI-level --allowedTools effectively replaces rather than merges with project settings.

Related

• Issue #695 — Same pattern with MCP tools: tag mode filters userAllowedMCPTools to only mcp__github_*.

Suggested Fix

The security hardening in PR #1002 is valid. But tagModeTools should merge project permissions.allow entries rather than ignoring them. Bash(...) allow rules from project settings don't bypass the git-push.sh wrapper or grant filesystem write access outside $GITHUB_WORKSPACE.