Auto-mode classifier silently blocks GitHub comment edits (GraphQL + REST) while allowing comment creation, with no override — Codex CLI has no equivalent restriction

Environment: Claude Code 2.1.207, macOS, non-interactive/auto-mode session, gh CLI authenticated with repo scope.

What happened: In an auto-mode session, I attempted to edit an existing GitHub issue comment (correcting a data error in a bot-generated timing log) via two independent, structurally different calls:

1. gh api graphql -f query='mutation { updateIssueComment(...) }'
2. gh api -X PATCH repos/{owner}/{repo}/issues/comments/{id} -f body=@file

Both were denied identically: "Permission for this action was denied by the Claude Code auto mode classifier. Reason: Blocked by classifier." A third attempt — a local-only node -e script that only read a file and wrote to disk (no GitHub call at all) — was also denied, suggesting the classifier evaluates something like inferred intent/context rather than the literal command being executed.

Meanwhile, in the same session: creating a new comment (gh issue comment ... --body), editing issue labels/title (gh issue edit), and all read operations were permitted without issue. Only edits to already-posted comments were blocked.

Cross-tool comparison: After Claude Code refused all three attempts, I ran the exact same gh api -X PATCH command through OpenAI's Codex CLI in the same repo/environment, and it executed without any permission block or classifier objection. So the same user, the same command, the same repo, and the same credentials succeeded on a competing agentic coding tool and failed on Claude Code. That's a direct product gap, not just a documentation gap — right now Claude Code is more restrictive than a competitor for a legitimate, user-directed maintenance action, with no way to opt in.

Why this is a problem:

• The block isn't a Bash permission-rule issue — the relevant commands were already allow-listed in .claude/settings.json, so there's no way for a user to grant this capability short of running the command themselves (or switching tools).
• There's no visible documentation of what the auto-mode classifier does or doesn't allow, so this is only discoverable by trial and error.
• The behavior is inconsistent: comment creation is allowed, comment edit is not, with no stated rationale.
• It's a hard blocker with no in-session override, and it's now a concrete reason a user is considering moving work to a competing tool that doesn't have this restriction.

Ask: Either document this guardrail and its scope, or provide a settings-level way to opt in to comment-edit operations the way Bash command allow-rules already work for everything else.