Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Analyzing Claude Code Transcript Patterns: Building Permission Allowlists for Frictionless Development

During a recent development session focused on JADA charter operations tooling, I needed to optimize my Claude Code workflow to eliminate permission prompts for frequently-used read-only commands. This post documents the systematic approach I took to analyze transcript data, identify common tool patterns, and configure a robust permissions allowlist.

What Was Done

I conducted a comprehensive analysis of 50 recent transcript files across multiple projects to identify which bash commands and tools were being invoked most frequently. The goal was straightforward: extract patterns from historical usage and pre-authorize the safe, read-only operations to prevent permission interruptions during future development sessions.

The analysis revealed that my workflow was dominated by standard Unix utilities—commands that Claude Code already auto-allows by default. However, several commonly-used tools were missing from my global permissions configuration. I then updated my settings file to include these missing entries and created a reusable allowlist pattern for future reference.

Technical Details: Transcript Analysis Methodology

The analysis process involved three distinct phases:

Phase 1: Transcript Discovery and Structure Validation

I located transcript files in the Claude Code cache directory at /Users/cb/.claude/ and extracted the 50 most recent files. Initial inspection revealed that transcript structure varies slightly depending on message type. The key insight was understanding the difference between:

  • Tool use entries: Located in message.content[].tool_use, containing id, name, and input fields
  • Command invocations: Stored within tool_use input as bash command strings
  • Message types: Including "user", "assistant", and "tool_result" entries that needed filtering

Initial parsing attempts failed because I incorrectly assumed a flat structure. After inspecting a sample transcript file, I discovered that tool_use data lives in nested arrays within the message content structure. The corrected parsing approach iterated through each message, checked for content arrays, and extracted tool_use blocks only when present.

Phase 2: Tool Pattern Extraction and Aggregation

Once I validated the transcript structure, I wrote extraction logic that:

  • Iterated through all 50 transcript files
  • Parsed JSON structures to find tool_use blocks
  • Extracted bash command names (the first word of each command string)
  • Aggregated counts across all transcripts
  • Sorted results by frequency to identify the most commonly used tools

The extraction revealed a clear hierarchy. Commands like grep (754 occurrences), find (112 occurrences), and ls (80 occurrences) dominated the usage pattern. No MCP tool calls were detected in the analyzed transcripts, confirming that my workflow is primarily bash-based.

Phase 3: Cross-Reference with Auto-Allow List

I then cross-referenced the extracted commands against Claude Code's built-in auto-allow list. The critical finding: Claude Code automatically permits any subcommand of these tools without prompting:

  • grep with any flags (e.g., -r, -n, -i)
  • find with any predicates
  • cat for reading files
  • ls for directory listing
  • echo for output
  • wc for line counting

This meant that the majority of my workflow was already friction-free. However, several commonly-used tools were not in the default auto-allow list, creating unnecessary permission prompts.

Infrastructure: Settings File Configuration

Claude Code permissions are stored in /Users/cb/.claude/settings.json, structured as a rules array with allow and deny patterns. Each rule follows this format:

{
  "allow": [
    "Bash(grep:*)",
    "Bash(find:*)",
    "Bash(sed:*)",
    "Bash(awk:*)",
    "Bash(sort:*)",
    "Bash(uniq:*)",
    "Bash(docker:*)",
    "Bash(cd:*)",
    "Bash(git:*)",
    "Bash(gh:*)"
  ]
}

The pattern Bash(command:*) means "allow this bash command with any subcommand or arguments." The asterisk is critical—it enables broad permission without requiring enumeration of every possible flag combination.

My updated settings now contain 49 total permission rules split between allow (41) and deny (8) lists. The deny list includes intentionally-blocked operations like rm, sudo, and network-modifying commands—a safety boundary that prevents accidental destructive operations even when I'm running in unrestricted mode.

Key Decisions and Rationale

Why Not Use Auto Mode?

Haiku 4.5 is Claude Code's fastest model, but it doesn't support auto mode. Auto mode exists only for larger models (Opus/Sonnet) where Claude can intelligently downgrade to cheaper models when appropriate. Since Haiku is already the endpoint, there's nothing smaller to downgrade to. The solution is pragmatic: use Haiku as the default for speed, and invoke /fast selectively when tackling complex reasoning tasks that demand Opus-level capability.

Why Allowlist Instead of Deny?

I chose to build an allow-based permission model rather than expanding the deny list. The reasoning:

  • Explicit over implicit: An allow list makes permissions intentional and auditable
  • Safer defaults: Commands not on the list require explicit approval, catching unexpected operations
  • Easier to extend: Adding a new safe command is a single allow-rule addition, not a hunt through deny logic

The deny list serves as a backstop for truly dangerous operations (like rm -rf / patterns), but the allow list is the primary control mechanism.

Why Include Docker and cd?

Docker inspection commands (docker ps, docker logs, etc.) are read-only and commonly used in development workflows. Including docker:* eliminates permission prompts for container inspection without enabling destructive operations. The cd command, while technically a shell builtin, is listed explicitly for clarity—it's navigation, not file manipulation, so it's safe to pre-authorize.

What's Next

With this allowlist in place, future Claude Code sessions will run friction-free for common development tasks. The next steps are:

  • Monitor for new patterns: As I tackle new projects, I'll identify additional tools that warrant allowlist inclusion and update the settings accordingly
  • Document project-specific tools: For repository-specific work (like the shipcaptaincrew project that emerged during this session), I may create project-scoped allowlists if certain tools are frequently needed
  • Establish deny-list review: Periodically review the deny list to ensure it still reflects my threat model for accidental destructive operations

The transcript analysis methodology itself is reusable—if you're running Claude Code frequently, the same extraction logic can identify