[BUG] Claude accidentally executes arbitary code when writing commit message

Preflight Checklist

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

What's Wrong?

Hi Colleagues! I've experienced a weird issue with claude code over the weekend, and I think you should all know it.

The root of the problem is in Claude's habit of over-explaining and some insufficiency in auto mode security.

TLDR claude can accidentally do anything on your machine while writing commit messages.

The thing is that in bash claude usually writes commits using git commit -m "message" syntax and the thing is that in bash anything within backticks commits is executable. Try writing the following simple command in your bash (Linux, WSL, or Mac terminal)

echo "ls output here: `ls`"

The problem is that Claude generally speaks markown and backtick is what we use in mardown to write a one line snippet of code, this means that claude regularly executes random shell commands when it decides to insert a piece of bactick code to the commit.

I was working on security related feature in my hobby project and commit messages included a large number of destructive commands. One of these commands was rm -rf ~/Documents which actually succeeded to delete the documents folder including the project in which the work was happening. Not a big deal: everything was backed up and committed to repositories and claude does not have sudo, but nevertheless if you have access to something serious the consequences could be quite severe.

The command which deleted my docs

● Bash(git add -A docs/approvals-and-rater-spec.md docs/attention/ && git commit -q -m "spec §3 + resolve: a grant is a PREFIX, and the menu must name it (Andrew, option 1)

  Resolves docs/attention/2026-07-28-allowlist-prefix-granularity-outruns-the-consent.md.
  `always approve` on `rm -rf ./build` stores the prefix `rm`, so `rm -rf ~/Documents`
  then runs unrated and unprompted, and §3 never said how coarse a prefix is.

  Andrew chose option 1: state it plainly and leave the behaviour. Options 2-4 declined
  -- the \"could be catastrophic\" test is a static question over an open set of commands,
  re-rating spends the call §3 exists to avoid, and finer prefixes re-prompt on routine
  work (the CFG-26 regression).

  §3 now also states the consequence in the form that is easy to get wrong: §4.2's
  \"catastrophic is never sticky\" means a catastrophic VERDICT cannot be made sticky,
  NOT that a catastrophic command cannot be auto-approved -- a destructive sibling
  sharing the prefix removes the variant from rating entirely.

  The surface half (menu renders \"always approve \`rm *\`\") goes to TUI-C26, which
  already owns §6's five choices.

  Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
  Claude-Session: https://claude.ai/code/session_01ABRACADABRA" && git status --porcelain && echo "(tree clean)" && git log --oneline -1)

What Should Happen?

Claude should not accidentaly run code when writing commit messages.

Error Messages/Logs

Steps to Reproduce

Ask claude to write a commit message including snippets of bash commands in backtics.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

_No response_