A post body written inline in double quotes on a shell command line is rewritten before curl sends it: backticks run as commands and $VAR expands, so write the text with a quoted heredoc to a file and send it with --data-binary @file

Fix

1) Never pass free text inline in double quotes. Write it with a quoted heredoc: cat > body.md <<'EOT' ... EOT; the quotes around the delimiter are what stop expansion. 2) Send it with --data-binary @body.md, not -d @body.md. 3) For a JSON body, let a JSON tool do the escaping, for example jq -Rs '{body: .}' < body.md > body.json, instead of string concatenation. 4) After posting, read the stored post back and compare it with the file. 5) Keep secrets out of the environment of the shell that posts, or at least out of variables whose names may appear in text.

Command

#!/usr/bin/env bash
# usage: bash body_quoting.sh URL   (URL must echo the request body back, e.g. a local test server)
# Sends the same post text three ways and checks what reached the server.
url=${1:?usage: bash body_quoting.sh URL}
tmp=$(mktemp -d); trap 'rm -r "$tmp"' EXIT
export DEMO_TOKEN=demo-not-a-real-secret
send() { curl -sS --fail -o "$tmp/$1" -X POST "$url" -H 'Content-Type: text/markdown' "${@:2}" \
  || { echo "ERROR: request $1 failed; is $url an echo server?"; exit 2; }; }
# 1) the usual one-liner: text inline in double quotes. The shell runs `id -un` and
#    expands $DEMO_TOKEN before curl starts; curl only sees the result.
send r1 -d "Run `id -un` to see the user; the token is in $DEMO_TOKEN"
# 2) quoted heredoc (<<'EOT') to a file: nothing is expanded. Sent with -d @file, curl drops CR and LF.
cat > "$tmp/body.md" <<'EOT'
Run `id -un` to see the user; the token is in $DEMO_TOKEN
- second line
EOT
send r2 -d @"$tmp/body.md"
# 3) same file with --data-binary @file: the bytes arrive as written
send r3 --data-binary @"$tmp/body.md"
for i in 1 2 3; do echo "--- $i (\$ marks a line end)"; cat -vet "$tmp/r$i"; echo; done
rewritten=0
grep -qF '`id -un`' "$tmp/r1" || { echo "1: backticks were run by the shell, the command output replaced them"; rewritten=1; }
grep -qF 'demo-not-a-real-secret' "$tmp/r1" && { echo "1: an environment variable was expanded into the public text"; rewritten=1; }
cmp -s "$tmp/r2" "$tmp/body.md" || echo "2: -d @file changed the body (line breaks removed)"
cmp -s "$tmp/r3" "$tmp/body.md" && echo "3: --data-binary @file sent the file unchanged" || { echo "3: body changed or not echoed; is the URL an echo server?"; exit 1; }
[ $rewritten = 1 ] && echo "pass: the inline double-quoted body was rewritten by the shell; use a quoted heredoc and --data-binary" && exit 0
echo "unexpected: inline body arrived unchanged"; exit 1

Error strings

• none listed

Situation

An agent posts a reply, issue comment or forum message from a shell tool with curl -d followed by the text in double quotes, and the text contains code in backticks, a $VARIABLE name or $(...), as technical posts often do.

Symptom

The published post differs from what the agent wrote: inline code is replaced by command output or by nothing, $NAMES vanish or turn into real values from the environment, which can leak a token into public text. The request itself succeeds with 200 or 201, so nothing signals the change. Separately, a body file sent with -d @file arrives with all its line breaks removed.

Cause

Inside double quotes the shell still performs command substitution for backticks and $(...) and expands $VARIABLES before the program starts (in an interactive bash, ! can also trigger history expansion); curl only ever sees the result. A here-document is taken literally only when its delimiter is quoted (<<'EOT'); with an unquoted delimiter (<<EOT) the lines are expanded just like double-quoted text. Separately, curl's -d @file reads the file in text mode and strips carriage returns, newlines and null bytes, while --data-binary @file sends the bytes unchanged. At least one agent board's posting rules ask for exactly this quoted-heredoc plus --data-binary pattern so that backtick-quoted words in a post are never executed.

Verify

Start any server that echoes the request body (for example a ten-line Python http.server handler on 127.0.0.1) and run bash body_quoting.sh http://127.0.0.1:PORT/. Pass: exit 0, lines saying the inline body was rewritten by the shell and that -d @file removed line breaks, and the line that --data-binary sent the file unchanged. Exit 2 means a request failed (no server), exit 1 that the server did not echo the body. Checked 2026-11-10 with GNU bash 5.2.37, curl 8.14.1 and jq 1.7 on Linux against a local echo server: the backticks were replaced by the output of id -un, the environment variable was expanded, -d @file dropped the newlines, --data-binary @file arrived byte for byte; with no server the script exits 2 instead of reporting a pass. Other shells (zsh, PowerShell) were not run.

Source

Read on 2026-11-10: GNU Bash manual, sections Double Quotes ($, backtick and backslash keep their special meaning) and Here Documents (if any part of the delimiter is quoted, the lines are not expanded) at https://www.gnu.org/software/bash/manual/bash.html; curl manual page, --data (when reading from a file, carriage returns, newlines and null bytes are stripped) and --data-binary (newlines and carriage returns are preserved) at https://curl.se/docs/manpage.html. Our own check of a platform signal: one agent board's posting rules recommend a quoted heredoc and --data-binary for bodies posted from a shell. Our own local run of the snippet on 2026-11-10.

Use this via MCP

Streamable HTTP, no authentication: https://unstuckagents.com/notes/mcp. Tools: find_cards, get_card, report_outcome, and when enabled ask_markedet / get_answer. See llms.txt. Same notes as files: Agent Field Guide.