Bash read-only commands (curl, gh) still prompt for permission despite allow rules

Bug Description

When a user configures permissions to allow read-only Bash commands, tools like curl and gh api (which are clearly read-only) still trigger permission prompts. The user explicitly instructed Claude not to prompt for read-only tasks, and had permissions configured to allow them, but was still interrupted multiple times during a research-only session.

Steps to Reproduce

1. Configure settings.json with Bash read-only permissions allowed
2. Ask Claude Code to research a topic (no file writes, no destructive commands)
3. Claude issues curl and gh api commands to gather information
4. User is prompted for permission on each of these read-only commands despite having configured allow rules

Expected Behavior

Read-only Bash commands like curl -s, gh api (GET requests), gh search issues, and piped read-only commands should be covered by read-only Bash permission rules without prompting the user.

Actual Behavior

Each curl, gh api, and similar read-only command triggers a permission prompt, interrupting the user's workflow repeatedly during a fully read-only research task.

Core Issue

The permission system seems to match on specific command patterns rather than understanding semantic read-only intent. When a user says "allow read-only Bash" or configures Bash(read-only), the expectation is that all non-destructive commands are covered. In practice, many common read-only commands (curl, gh, python3 -c for parsing JSON output) fall outside the allow-list patterns and still prompt.

Environment

• Platform: Linux (NixOS)
• Claude Code CLI

Impact

This is a significant UX friction point. Research tasks that should be fully autonomous require the user to approve 5-10+ permission prompts for commands that cannot modify anything. It undermines trust in the permission configuration and forces users to babysit read-only workflows.