Ability to run "/graphify ." in claude in a headless mode

[lyveng]

Background

I've been using the /graphify skill inside Claude Code (desktop app) and hit a persistent UX problem: almost every step in the pipeline prompts for permission, even after correctly configuring .claude/settings.local.json with allowlist entries.

What I tried first

The skill executes Python via $(cat graphify-out/.graphify_python) -c "...". I added the following to my project's .claude/settings.local.json:

{
  "permissions": {
    "allow": [
      "Bash($(cat graphify-out/.graphify_python) *)"
    ]
  }
}

This didn't work. After investigation, I found two issues:

1. $ and () are likely treated as special characters (regex/glob metacharacters) in Claude Code's pattern matching engine — the pattern silently fails to match.
2. Standard glob * may not match newlines, and the multiline -c "..." blocks span multiple lines.

Fix attempt 1: resolved interpreter path

Replaced the $(cat ...) pattern with the actual resolved path:

{
  "permissions": {
    "allow": [
      "Bash(/Users/livingstone.se/.local/share/uv/tools/graphifyy/bin/python3 *)"
    ]
  }
}

This got past the basic allowlist check — but prompts still appeared. Reason: Claude Code has security-level checks that run above the allowlist layer and cannot be suppressed by any allowlist entry.

The security checks that fire

Two distinct heuristics were observed:

1. \n# check — fires when a Python comment (# ...) follows a newline inside a -c "..." or heredoc argument:

   "Newline followed by # inside a quoted argument can hide arguments from path validation"

2. Brace-quote check — fires on Python f-strings with dict access like {len(result["nodes"])}:

   "Contains brace with quote character (expansion obfuscation)"

Both checks scan the entire command string, including heredoc bodies — switching from -c "..." to << 'EOF' heredoc syntax doesn't help. The heuristics can't distinguish Python f-string syntax from shell expansion obfuscation tricks like ${IFS}rm${IFS}-rf.

Result: Every step that contains either a # comment or a dict-access f-string will always prompt, regardless of any allowlist configuration.

Proposed fix: scripts/pipeline.py

If the skill's inline Python blocks were extracted into a versioned script at ~/.claude/skills/graphify/scripts/pipeline.py, invocations would become:

/path/to/python3 ~/.claude/skills/graphify/scripts/pipeline.py detect .
/path/to/python3 ~/.claude/skills/graphify/scripts/pipeline.py ast
/path/to/python3 ~/.claude/skills/graphify/scripts/pipeline.py build

The allowlist entry would be a single static pattern:

"Bash(/Users/me/.local/share/uv/tools/graphifyy/bin/python3 /Users/me/.claude/skills/graphify/scripts/pipeline.py *)"

No inline code in the command string → no heuristic triggers → zero prompts after initial setup.

Questions for the maintainer

1. Is there some way of avoiding these many prompts when running graphify claude skill? Am I missing something?
2. Is there a reason the skill uses inline -c "..." blocks instead of a bundled script? (Portability? Avoiding a separate install step?)
3. Is a scripts/pipeline.py approach on the roadmap, or would a PR be welcome?
4. Has this been tested with Cursor or OpenCode? Do those tools have similar security heuristics that would trigger on the same patterns? Would be useful to know if this is a Claude Code-specific problem or a general agentic-tool concern.

P.S.
I have not validated the internals of claude code. Those are mostly generated by claude based on my trial of getting the skill to run headless inside claude. Nevertheless the observations on how claude code ignored the allowlist entries are original.