fix(agents): stop dropping and mangling `cumora reply --file` bodies (#11)
`--file` / `--stdin` exist so a body that was never shell-quoted reaches Cumora verbatim — the shim's own comment promises "code/quotes/$ survive verbatim", and the persona the daemon writes tells every BYOA agent to use `--file` for anything with backticks, code, `$`, quotes, or newlines. Two bugs broke that promise, both because the content was spliced into argv as an ordinary positional: 1. parseArgs classifies any token starting with `--` as a flag, so a body opening with a markdown rule (`---`), a YAML front-matter fence, or a diff header (`--- a/src/foo.ts`) never reached cmdReply's positional.slice(1). The agent got back `usage: reply <convo_id> "<body>"` for a command it had written correctly, and the message was never posted — from the human's side the teammate simply went silent. 2. cmdReply ran unescapeChat over it. That helper exists because the bash tool single-quotes inline bodies, so `\n` arrives as two literal characters — but --file content never met a shell. A `\n` inside a string literal became a real line break and `C:\\Users\\dev` lost a level, corrupting exactly the code snippets the flag is advertised for. Fix both with one mechanism: the shim now appends the body last, behind a POSIX `--`, and parseArgs honors `--` as end-of-flags, recording where literal args begin so cmdReply can join them without re-expanding escapes. parseArgs previously read `--` as a zero-length-key flag that swallowed the following token. The test pinning that noted "no caller depends on `--` either way today" and that POSIX would end flags there; it is updated to the POSIX meaning, which is now load-bearing. Absent a `--`, the parsed object is unchanged, so every existing caller behaves exactly as before.
X
Xialie Zhuang committed
87acdf7ac0c8a1b9b0627613069f2cb39857c427
Parent: c36d5cc
Committed by GitHub <noreply@github.com>
on 8/19/2026, 5:27:20 AM