## Summary `glab orbit remote query` errors with `Invalid character '@' looking for beginning of value` whenever `response_format` resolves to `llm` (the documented default). The same query with `response_format: raw` succeeds and returns valid JSON. The error is post-server: the API returns `200 OK` with a valid response body, but the CLI's `llm` formatter chokes parsing it. This blocks the agent-oriented default workflow described in the [`orbit` skill](https://gitlab.com/gitlab-org/orbit/knowledge-graph/-/blob/main/skills/orbit/SKILL.md), which says: *"Default output is `llm` (compact, agent-friendly); pass `--format raw` to pipe into `jq`."* Today the documented agent-friendly default never works. ## Reproducer Body (`/tmp/uc9-warmup.json`): ```json { "query": { "query_type": "traversal", "nodes": [ {"id": "p", "entity": "Project", "filters": {"id": {"op": "eq", "value": 278964}}}, {"id": "mr", "entity": "MergeRequest", "filters": {"state": "merged"}, "columns": ["iid", "title", "merged_at", "merge_commit_sha"]} ], "relationships": [ {"type": "IN_PROJECT", "from": "mr", "to": "p"} ], "order_by": {"node": "mr", "property": "merged_at", "direction": "DESC"}, "limit": 5 } } ``` ```console $ glab orbit remote query /tmp/uc9-warmup.json ERROR Invalid character '@' looking for beginning of value. $ glab orbit remote query /tmp/uc9-warmup.json --format raw {"result":{"format_version":"2.0.0","query_type":"traversal","nodes":[...]},"query_type":"traversal","row_count":5} ``` The `--format raw` invocation returned the expected payload — 5 MergeRequests + a Project node with edges. The query itself is valid; the failure is purely in the `llm` response formatter. ## Reproduces across all triggers for `llm` | Invocation | Result | |---|---| | `glab orbit remote query body.json` (CLI default) | ❌ `Invalid character '@'` | | `glab orbit remote query body.json --format llm` (explicit CLI flag) | ❌ `Invalid character '@'` | | `body.json` contains `"response_format": "llm"` (body field) | ❌ `Invalid character '@'` | | `cat body.json \| glab orbit remote query -` (stdin) | ❌ `Invalid character '@'` | | `glab orbit remote query body.json --format raw` | ✅ works | | `body.json` contains `"response_format": "raw"` | ✅ works | So the bug is in the `llm` format path, not in the CLI flag handling, body parsing, file-vs-stdin, or query shape. ## Environment - `glab` version: `1.94.0 (aa456f48)` - Endpoint: production Orbit (`POST /api/v4/orbit/query` on gitlab.com) - Project queried: `gitlab-org/gitlab` (ID 278964) — confirmed indexed (`--format raw` returned 5 recent merged MRs) - The server is returning `200 OK` with valid data (proven by `--format raw` returning the same query's results without issue) ## Impact - **Customer-zero testing impact:** Agents (in-app Orbit Agent and OpenCode equivalents) targeting the documented agent-friendly default will hit this error on every query. The workaround (`--format raw`) is fine for human-driven sessions but breaks the "drop-in agent-friendly format" promise the skill makes. - **Discoverability:** The error message `Invalid character '@' looking for beginning of value` does not name the format or the source of the offending character, making this hard to diagnose without isolating the format axis. ## Suggested severity `severity::3` — functionality is broken but a documented workaround exists. Bump to `severity::2` if the team confirms the `llm` format is on the public-beta path. ## References - Skill docs that recommend the broken default: <https://gitlab.com/gitlab-org/orbit/knowledge-graph/-/blob/main/skills/orbit/SKILL.md> - Parent customer-zero issue: gitlab-org/orbit/knowledge-graph#602 - Surfaced during UC-9 warm-up under gitlab-org/orbit/knowledge-graph#605 - Customer Zero bug-reporting epic: gitlab-org&21852