Generated shell commands contain unreplaced <placeholder> tokens (pasted verbatim -> broken/destructive runs)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 21, 2026

Environment: Claude Code (VSCode extension), Windows 11 / PowerShell.

Problem: Claude Code frequently hands over runnable shell commands that contain angle-bracket placeholder tokens it expects the user to substitute. Because the practical workflow is copy-paste-verbatim, the literal token reaches the shell and breaks the command — sometimes destructively.

Worst concrete instance: a helm upgrade … --set image.tag=<the-tag-from-above> command was pasted as-is, so the literal string <the-tag-from-above> was deployed as the container image tag — putting the app on a non-existent image and requiring a corrective redeploy. The correct value had been printed by the immediately preceding command and could simply have been hardcoded.

Other instances in the same session: kubectl drain <node>, <cluster-name>, <pod-name> placeholders left inside otherwise-complete commands.

Expected: Any command presented in a fenced code block should be runnable exactly as pasted — every value either resolved to a literal, self-populated within the same block (e.g. captured into a shell variable via a preceding query), or, if a single user-supplied value is genuinely unavoidable, isolated on its own clearly-marked line rather than buried mid-command.

Impact: Repeated wasted round-trips and one broken deployment. Recurred multiple times within a single session even after being explicitly flagged by the user.

Suggested fix: Treat a fenced command block as a runnable artifact, not an annotated illustration — resolve or self-populate every value, and keep explanation in the surrounding prose rather than inside the block.

View original on GitHub ↗