claude-code - 💡(How to fix) Fix [BUG] Permission-suggestion UI generates malformed rule (unclosed quote) for git commit heredoc patterns; sometimes crashes the dialog

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When the VS Code extension auto-generates permission-rule suggestions for a git commit -m invocation that uses a heredoc + nested single-quote pattern for the message body, the extracted ruleContent is malformed (contains an unclosed '). The resulting suggestion dialog either renders a broken rule or fails to open at all.

The underlying tool call (Bash) succeeds; the issue is in the auto-suggest extractor that runs after the call completes.

What Should Happen?

Expected The extractor should either:

(a) Skip generating a suggestion when the command can't be cleanly globbed (heredoc, complex quoting, etc.), or (b) Emit a well-formed pattern, e.g. git commit -m "*" (double-quoted), or (c) Escape the inner quote so the rule string is valid as input to the permission matcher. The dialog should render without errors and any rule it presents should be valid.

Actual The harness emits an addRules payload whose ruleContent has an unclosed single quote:

{ "type": "addRules", "rules": [ { "toolName": "Bash", "ruleContent": "git add *" }, { "toolName": "Bash", "ruleContent": "git commit -m ' *" } ], "behavior": "allow", "destination": "localSettings" } Notice git commit -m ' * — the apostrophe before * is never closed. Verbatim copy from the extension log:

2026-05-15T19:11:10.534Z [DEBUG] "Permission suggestions for Bash: [ { "type": "addRules", "rules": [ { "toolName": "Bash", "ruleContent": "git add *" }, { "toolName": "Bash", "ruleContent": "git commit -m ' *" } ], "behavior": "allow", "destination": "localSettings" } ]" 2026-05-15T19:11:10.534Z [DEBUG] executePermissionRequestHooks called for tool: Bash On at least some invocations the dialog itself fails to render (screenshots attached). On others it renders the malformed rule and a click on "Allow" appears to either no-op or persist a permission entry that doesn't match the intended pattern.

Error Messages/Logs

Steps to Reproduce

In a session where the harness has not yet whitelisted Bash(git commit:*):

Have Claude run a multi-line commit using the canonical pattern from the system prompt's "Committing changes with git" section:

git commit -m "$(cat <<'EOF' summary line

body paragraph

Co-Authored-By: … EOF )" The Bash call executes successfully — git log shows the commit landed.

The harness then generates a permission-rule suggestion via its Permission suggestions for Bash flow.

Observe the rule content in the extension's debug output channel OR the corresponding "would you like to add this rule?" dialog.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.141.e27

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

Root cause hypothesis (from outside the codebase) The pattern extractor likely splits the command on whitespace and tries to substitute * for the message body. The heredoc body opens with "$(cat <<'EOF' whose ' confuses a naive tokenizer; the first word after -m becomes the orphan ' token, the trailing * follows, and the rule is closed without re-balancing the quote.

Impact The user must dismiss a broken dialog after every git commit -m heredoc invocation, OR Risks accepting a rule that doesn't match what they think it does (the git commit -m ' * literal won't match future git commit -m "…" calls; the permission appears to apply but doesn't). Heredoc is the recommended pattern for multi-line commit messages in Claude Code's own system prompt ("In order to ensure good formatting, ALWAYS pass the commit message via a HEREDOC"), so this isn't avoidable for users following documented practice without a workaround.

Workaround in use Switching to inline git commit -m "summary\n\nbody\n\n…" with \n escapes avoids the bug but produces uglier git log --format=%B output (literal \n sequences rather than paragraphs).

Attachments Screenshots of the malformed / failed permission dialog (attached below). Extension debug log excerpts (above).