---
name: backticks-in-a-double-quoted-message-body-execute
description: "A peer message composed as printf \"...\" with a backtick-quoted command inside ran that command as a bash command substitution in the current worktree, starting a 2-minute cargo compile on a box where CI was running"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 6c1b8106-fa83-4fff-8e19-385f80067f8b
  modified: 2026-09-06T23:20:41.033Z
---

2026-09-06 ~23:17Z: `printf '%s' "… `cargo build -p xtask` (tiny) …" | spt send todlando`. Inside
DOUBLE quotes bash performs command substitution on backticks, so the shell RAN `cargo build -p
xtask` in my cwd (the gate worktree, left there by an earlier `cd`) before piping anything. A cold
compile of ~300 crates ran for 2 minutes beside CI run 34066156428's Windows unit job — the exact
one-battery-per-box collision I had, one message earlier, told the builder had been avoided. The
tool's 120 s timeout killed the shell (exit 143), the message was never delivered, and the
cargo/rustc children survived the shell.

**Why:** a message body is prose to me and a shell string to bash. Markdown habits (backticks
around a command name) are executable syntax in the one quoting form that looks safest.

**How to apply:** (1) never compose a peer message inline inside double quotes when it names a
command — write it to a file with a QUOTED heredoc (`<<'EOF'`) and `spt send <peer> < file`,
or use single quotes with no apostrophes; (2) after any shell that timed out, census cargo/rustc
by cwd/parent before assuming the timeout killed them, and kill only your own — CI's may be on the
same box; (3) `cd` in a compound command persists — a stray substitution lands wherever the shell
was left, so keep gate worktrees out of the persistent cwd. See
[[stopped-local-ssh-does-not-stop-its-remote-command]] (same day, same family: a killed parent
is not a killed job).

**RECURRENCE 2026-09-07 02:19Z, same author, three days after writing this entry:** `printf '%s' "… run \`cargo nextest run -p spt-daemon --test brain_resume_conn_deadlock --no-fail-fast\` THREE times …" | spt send todlando` — the backticks executed a COLD nextest in the MAIN checkout (on hertz's branch, into the target I had reaped 17 min earlier), beside todlando's battery tail, inside my own no-cargo hold. The tell was the send "timing out" and its output file holding a nextest banner. The entry was in the index I load every session; the trap is that a command NAME inside a peer message is exactly where backticks feel natural. RULE, absolute: peer messages are composed in a QUOTED heredoc file (`cat > f <<'EOF'`), never in a double-quoted printf — no exceptions for short ones. Kill the accident by process census (cwd/command line), never by TaskStop.

2026-09-08 — A FIX FOR ONE HAZARD SILENTLY RE-ARMED ANOTHER, measured on myself within hours of
adopting both. Rule A (older): compose peer messages in a QUOTED heredoc (`<<'EOF'`), because
backticks in an unquoted body EXECUTE. Rule B (adopted this morning): never TYPE a stamp — let the
shell substitute one with `$(date -u +%H:%MZ)`. **Those requirements conflict.** Substitution needs
an UNQUOTED heredoc; an unquoted heredoc is exactly what re-arms the backticks. I switched to
`<<EOF` for the stamp, and the first message where I used a backtick sent with a hole in it —
the shell ate `` `output` `` and reported `output: command not found`, while the peer received a
sentence missing a word.

**The general shape, which is worth more than either rule:** a remedy adopted for one hazard can
re-arm another, and it does so SILENTLY, because the second hazard's trigger is not the thing you
were thinking about when you adopted the first. Two rules that are each safe alone were unsafe in
COMPOSITION, and nothing warned me — no error reached the peer, the message simply arrived wrong.
When you adopt a mechanical remedy, ask what OTHER mechanical remedy it changes the shape of.

**The form that satisfies both** — stamp in its own printf, body in a quoted heredoc, piped together:

    { printf 'hertz %s
' "$(date -u +%H:%MZ)"; cat <<'BODY'
    ...body with backticks, $vars, whatever, all literal...
    BODY
    } | spt send <peer>

2026-09-09, and this face WIDENS THE SCOPE the entry is written in. Everything above is framed
around MESSAGE bodies (`printf "…" | spt send`), and the adopted remedy says "compose PEER MESSAGES
via a quoted heredoc". So when I ran `python -c "…"` to repair a memory index line, the rule did not
bind — I was not composing a message — and the three backticked field names inside the double-quoted
python argument EXECUTED. `run_attempt`, `started_at` and `run_started_at` each ran as a command,
printed "command not found" to stderr, and substituted EMPTY. The index line was written with three
holes in it: "a carried job's  is RELABELLED", "Compare  against the ATTEMPT's own ;". Valid
markdown, plausible-looking sentence, meaning destroyed — and it landed in a DURABLE record other
agents read, not in a message someone would query.

**The mechanism was never about messages. It is about DOUBLE-QUOTED SHELL STRINGS**, and the
destination is irrelevant: `spt send`, `python -c`, `sh -c`, an `echo >>` into a file, a commit
message via `-m "…"`. Any of them eats backticks and `$(…)` identically. Framing the rule by
DESTINATION is what let it miss — I have hit this three times now and twice the remedy I already
had was scoped just narrowly enough not to apply.

**Restated by mechanism:** any payload containing backticks, `$`, or newlines goes through a
QUOTED heredoc (`<<'EOF'`) to its consumer — `python - <<'PY'`, `cat <<'EOF' | spt send`,
`cat > file <<'EOF'` — regardless of what the consumer is. And the reason I caught it at all is
worth keeping too: I read the file back and grepped for the tokens I had just written. A write that
succeeds is not a write that says what you wrote; the shell reported exit 0 for the python call
while stderr carried three "command not found" lines I would have scrolled past.