`workiq ask` crashes with JSON parse error on every query (streamed/multi-object response not handled)

Summary

Every workiq ask invocation fails with a System.Text.Json parse error, regardless of query content — including trivial ones like ask -q "hi". Auth, Microsoft Graph, and the underlying binary are all healthy; only the ask command's response parsing is broken. This has been failing for days.

Component: @microsoft/workiq CLI (ask command)
Severity: High — the ask command is 100% non-functional.

Environment

Repro

> workiq ask -q "hi"
Error: '{' is invalid after a single JSON value. Expected end of data. Path: $ | LineNumber: 0 | BytePositionInLine: 887.

Fails identically for ask -q "say hello in one word.", ask --file-urls "<sharepoint-url>" -q "...", etc.

Root-cause hypothesis

The error is a .NET System.Text.Json JsonReaderException — the parser consumes one complete JSON object, then hits a second { and throws "Expected end of data." This is the classic signature of a streamed / NDJSON (newline-delimited, multi-object) response being handed to a single-object JsonSerializer.Deserialize call.

Confirming evidence: BytePositionInLine is independent of query length but tracks response size — e.g. "hi" → 887, longer file-url queries → 2772 / 3491. So the CLI reaches the backend and receives a response; it's the client-side deserialization of a multi-object stream that fails.

Likely a CLI ↔ backend protocol version mismatch: the service now returns streamed/chunked JSON objects, but this CLI build (28144) still deserializes the body as a single object.

Secondary bug

The process exits with code 0 despite the fatal error (observed EXITCODE=0), so callers/wrappers cannot detect the failure programmatically. It should exit non-zero on parse failure.

What works (scoping)

• M365 sign-in status → OK (signed in)
• In-process MCP tools (get_my_profile, get_recent_files) → OK
• workiq.exe --version → OK
• Only the CLI ask command → FAILS

Suggested fix

• Parse the ask response as a stream of JSON objects (NDJSON) / handle chunked or SSE framing rather than Deserialize<T> on the whole body.
• Return a non-zero exit code on parse failure.
• Add a CLI/service protocol-version check with a clear error message on mismatch.

Start by reproducing workiq ask -q "hi" and tracing the ask command's System.Text.Json response parsing. Confirm how the streamed or multi-object response is framed, then verify that parse failures produce a non-zero exit code; done means ordinary ask queries succeed and failures are detectable by callers.