A single **inline** comment tail on a content line — `{"a": {...}} // note` — empties every entry in that file (the whole menu for the default file, all of the user's additions for the extension). Full-line comments are handled; a comment at the end of a line silently kills every row.

Reproduced on `quattro` (`3faafba2`, 2026-09-27), using the repo's own parser, stock file fetched straight from this repo, and then on the #13968 head `b2dae8db` (narrated, 40s):

https://github.com/user-attachments/assets/9edfcdb0-a1a1-4316-b015-3cf5bf7ffbca

**Repro** (run from the repo root, node ≥ 18):

```js
// repro.js
const m = require("./shell/plugins/menu/MenuModel.js");

console.log(m.parseMenuJsonc('{"a": {"label": "A"}} // note'));
// expected: one row "A"   actual: [] — the whole menu is gone

console.log(m.parseMenuJsonc('{"a": {"label": "A"}}').map(r => r.label));        // ["A"]  no comment: fine
console.log(m.parseMenuJsonc('// note\n{"a": {"label": "A"}}').map(r => r.label)); // ["A"]  full-line comment: fine
console.log(m.parseMenuJsonc('{"a": {"label": "A // B"}}').map(r => r.label));     // ["A // B"]  // in a string: data
```

**What happens.** The comment stripper in `stripJsonc` is line-anchored:

```js
.replace(/^\s*\/\/[^\n]*(\n|$)/gm, "")
```

so an inline tail after content never matches and survives stripping. `JSON.parse` then throws on the leftover `// note`, and the `catch` in `parseMenuJsonc` silently returns an **empty item set**. One trailing comment → zero menu rows, no error surfaced.

**Blast radius.** JSONC's whole point is allowing comments; a user who documents an entry inline (`"reboot": { … } // firmware-safe reboot`) loses every entry in that file and gets no hint why. The failure is silent and total rather than local to the commented line.

**Fix.** Strip inline comment tails too, but string-aware: `//` inside a string literal (`"A // B"`) is data and must stay verbatim — the same requirement the trailing-comma scanner in #13255 already honors. That fix went out as #13512, which extended that scanner to comments. It fixed the inline tail but broke a neighbouring shape — a trailing comma followed by a `//` comment line and then `}`. That is what the shipped sample extension becomes once its example rows are uncommented, so the whole file parsed to nothing (thanks @llstrk for catching it). The fix now lives in #13968, which replaces #13512, also fixes #13250 and #13492, and handles both shapes:

```sh
node -e 'const m=require("./shell/plugins/menu/MenuModel.js"); for (const s of [`{"a": {"label": "A"}} // note`, `{\n  "a": {"label": "A"},\n  // "b": {"label": "B"},\n}`]) console.log(m.parseMenuJsonc(s).length)'
```

| Rows parsed (both should be 1) | inline tail | comma, comment line, `}` |
|---|---|---|
| `quattro` `8b4eae6` | 0 | 1 |
| #13512 `f75205f` | 1 | 0 |
| #13681 `6acbace` | 1 | 0 |
| #13968 | 1 | 1 |

A 21-second capture of the shipped parser on `quattro` `8b4eae6` and then with the fix in #13968 (`b2dae8db`), reading a menu whose last entry ends with a trailing comma and an inline `// favorites` comment, and the shipped sample config with its examples enabled: `quattro` returns 0 rows, the fix returns all 3:

https://github.com/user-attachments/assets/c1b4fc51-112c-4316-b5ac-7f744f7e6a62

<sub>Independent verification: [our validation of this report](https://portal.reqproof.com/projects/omarchy/inbox/28#validation) (reproducer and verdict) · [the known-issue record](https://portal.reqproof.com/projects/omarchy/findings/KI-MENU-JSONC-INLINE-COMMENT) (status and tests).</sub>

---

**Updated 2026-10-01:** still reproduces on `quattro` `8b4eae6`; my #13512 broke a trailing comma followed by a `//` comment line, so the fix now lives in #13968, which handles both shapes; added a 21-second capture of the bug and the fix. Also 2026-10-02: the repro commit now names the `quattro` tip at filing time (the earlier SHA was from my mirror of `quattro`; the parser is identical), and the blast radius says what is actually lost: every entry in the file with the comment. Replaced both videos. The narrated one now runs this issue's repro on `3faafba2` and on the #13968 head, instead of showing #13512's branch as the fix; the short one is re-recorded on the #13968 head with every result readable.