[FEATURE] Avoid shell quoting issues when passing markdown to CLI tools like gh

Resolved 💬 5 comments Opened Feb 28, 2026 by claybridges Closed Apr 3, 2026

Problem Statement

Claude Code frequently generates broken shell commands when passing markdown text to CLI tools like gh pr create, gh pr edit, and gh issue create. The root cause is that markdown bodies often contain apostrophes, backticks, and other characters that conflict with bash quoting, and Claude struggles to produce correct quoting consistently.

In a single session, I hit this issue 4+ times across different gh commands. Each time Claude had to retry with a different quoting strategy, wasting time and cluttering the conversation.

Examples of broken commands

Apostrophe in heredoc breaks single-quoted delimiter:

gh pr create --title "My PR" --body "$(cat <<'EOF'
Dependabot can't do `.xcodeproj` dependencies
EOF
)"
# Result: /bin/bash: eval: unexpected EOF while looking for matching `'

Backticks in body conflict with bash:

gh issue create --body "$(cat <<'EOF'
`AccountStorage.accountIds` is an `[Account.Id]`
...they shouldn't exist
EOF
)"
# Result: /bin/bash: eval: unexpected EOF while looking for matching `'

Single-quoted variable with apostrophe:

BODY='Dependabot can'\''t do this'
# Often mis-escaped or Claude forgets to escape

How to reproduce

  1. Ask Claude Code to create a GitHub PR or issue where the body contains both backticks and apostrophes (contractions like "can't", "shouldn't", "it's")
  2. Example prompt: "Create a GitHub issue titled 'Fix auth bug' with a body that says: The authManager class can't handle the edge case where it's nil"
  3. Claude will typically generate a broken gh issue create command that fails due to quoting

This happens reliably when the markdown body contains a mix of:

  • Backtick-wrapped code references
  • English contractions (apostrophes)
  • The $(cat <<'EOF' ... EOF) heredoc pattern

Proposed Solution

Provide guidance or a built-in mechanism to avoid shell quoting entirely when passing multi-line text to CLI tools. Options:

  1. Recommend --body-file pattern in system prompt: Always write the body to a temp file first, then use gh --body-file /tmp/body.md. This completely sidesteps shell quoting.
  1. Built-in tool for GitHub operations: A dedicated tool (like the existing WebFetch) for common gh operations (create issue, create PR, edit PR body) that accepts the body as a tool parameter rather than a shell string.
  1. At minimum, add a system-level hint that when using gh commands with markdown bodies, Claude should default to writing a temp file and using --body-file.

Alternative Solutions

  • Manually avoiding apostrophes/backticks in generated text (fragile, Claude often forgets)
  • Using escaped single quotes ('\'') — works but Claude generates this incorrectly ~50% of the time
  • Adding project-level CLAUDE.md rules (what I'm doing now as a workaround, but this should be solved globally)

Additional Context

  • Claude Code version: 2.1.63
  • Model: Claude Opus 4.6
  • This affects any CLI tool that accepts multi-line text arguments, not just gh
  • The --body-file workaround is simple and reliable — it just needs to be the default pattern

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗