Summary
tasks-axi show <id> --full --json (and tasks-axi list --json) accept the flag and emit non-JSON output. A consumer that pipes to a JSON parser gets a parse failure, and a consumer that swallows the failure gets an empty result that is indistinguishable from "this task has no body".
This destroyed a record for us. A tool wrote the empty parse result back as the task body, replacing a considered note with nothing. The flag being accepted is what makes it dangerous: an unrecognised flag would have errored and cost nothing.
Reproduction
$ tasks-axi show <some-id> --full --json | python3 -c "import json,sys; print(json.load(sys.stdin))"
Traceback (most recent call last):
...
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
The same shape occurs with tasks-axi list --json.
Observed on the version bundled with our fleet as of 2026-08-05.
Why this is worse than a missing feature
Success and emptiness are reported identically. A caller cannot distinguish:
- the task genuinely has an empty body, and
- the output could not be parsed at all
Both produce an empty string. Any consumer that then writes based on that value performs a destructive operation on the strength of a failed read.
Suggested fix, in preference order
- Emit real JSON for
--json on show and list. add already appears to honour it, so the flag reads as supported.
- If
--json is not supported on these subcommands, reject it with a non-zero exit and a message naming the subcommand. A refusal is cheap; a silent wrong shape is not.
Either fix removes the failure mode. The second is trivial and could ship immediately.
What we are doing on our side
Adding a consumer-side guard: empty --json output is treated as an error, never as an empty set, and no write proceeds from an unparseable read.
Summary
tasks-axi show <id> --full --json(andtasks-axi list --json) accept the flag and emit non-JSON output. A consumer that pipes to a JSON parser gets a parse failure, and a consumer that swallows the failure gets an empty result that is indistinguishable from "this task has no body".This destroyed a record for us. A tool wrote the empty parse result back as the task body, replacing a considered note with nothing. The flag being accepted is what makes it dangerous: an unrecognised flag would have errored and cost nothing.
Reproduction
The same shape occurs with
tasks-axi list --json.Observed on the version bundled with our fleet as of 2026-08-05.
Why this is worse than a missing feature
Success and emptiness are reported identically. A caller cannot distinguish:
Both produce an empty string. Any consumer that then writes based on that value performs a destructive operation on the strength of a failed read.
Suggested fix, in preference order
--jsononshowandlist.addalready appears to honour it, so the flag reads as supported.--jsonis not supported on these subcommands, reject it with a non-zero exit and a message naming the subcommand. A refusal is cheap; a silent wrong shape is not.Either fix removes the failure mode. The second is trivial and could ship immediately.
What we are doing on our side
Adding a consumer-side guard: empty
--jsonoutput is treated as an error, never as an empty set, and no write proceeds from an unparseable read.