JSON body comments are not stripped in the VS Code extension: the request is sent as a quoted string

[alanmdza]

Summary

Comments in a body:json block are not stripped by the VS Code extension, and the request ends up being sent as a JSON string instead of a JSON object. The same collection works fine in the desktop app, which strips comments with decomment.

The whole body arrives at the server wrapped in double quotes, as a single JSON string, instead of an object. On a strict API this surfaces as a confusing 400 — our Django/DRF backend answers Invalid data. Expected a dictionary, but got str.

Details

Extension version: 5.0.2 (v5.0.2-2026.08.20)
VSCode version: 1.134.0
OS: Windows 11
Also affects the desktop app? No — Bruno 4.1.0 desktop sends the same request correctly.

Root cause

src/extension/ipc/network/prepare-request.ts builds the body like this:

case 'json':
  headers['content-type'] = headers['content-type'] || 'application/json';
  try {
    return body.json ? JSON.parse(body.json) : undefined;
  } catch {
    return body.json;
  }

Any // comment makes JSON.parse throw, so the catch returns the raw commented text. That string is handed to axios with content-type: application/json, and axios' stringifySafely cannot parse it either, so it falls back to JSON.stringify(rawString) — the body goes out double-encoded, as a quoted string.

Correction to an earlier version of this issue: decomment is not a dependency of this repo. src/extension/utils/script-runner.ts declares a local decomment that currently returns the script untouched, so nothing strips comments anywhere in the extension. The desktop app and the CLI do apply the real package to the body:

• packages/bruno-electron/src/ipc/network/prepare-request.js -> axiosRequest.data = decomment(request?.body?.json)
• packages/bruno-cli/src/runner/prepare-request.js -> same

So a collection authored in the desktop app (where JSON body comments are supported since usebruno/bruno#396) silently breaks when the same .bru files are run from VS Code. In our shared collection, 80 of 127 requests with a JSON body are affected.

Steps to reproduce

1. Create a request with a commented JSON body:

meta {
  name: comment-repro
  type: http
  seq: 1
}

post {
  url: https://echo.usebruno.com
  body: json
  auth: none
}

body:json {
  {
    "a": 1 // this comment breaks it
  }
}

2. Send it from the VS Code extension and look at the request body in the Timeline.
3. Remove the comment and send it again.

Actual: with the comment, the payload is the body text itself, quoted and escaped as a single JSON string. Without the comment, the object is sent correctly.
Expected: the comment is stripped and the object is sent, the way the desktop app does it.

Suggested fix

Strip the comments in the json case of prepare-request.ts, and make the fallback return the
comment-free text rather than the raw body:

case 'json': {
  headers['content-type'] = headers['content-type'] || 'application/json';
  if (!body.json) return undefined;
  const json = stripJsonComments(body.json);
  try {
    return JSON.parse(json);
  } catch {
    // Unquoted variables are only resolved later, by interpolation.
    return json;
  }
}

The fallback matters: a body that mixes comments with unquoted variables ("quantity": {{qty}})
is still not valid JSON after stripping, so it takes that path, and returning the raw text keeps
the // in the string that reaches interpolate-vars — those requests stay double-encoded.

PR: #138. Since decomment is not a dependency here, it adds a small dependency-free helper
rather than pulling the package in; swapping it for decomment to match bruno-electron byte for
byte is a one-line change if that is preferred.

Related upstream: usebruno/bruno#396 (comments in JSON body, implemented for desktop/CLI) and usebruno/bruno#8055 (invalid JSON bodies being quoted).

[alanmdza]

One correction to the fix I suggested in the description: the catch should fall back to the decommented text, not to the raw body.json.

case 'json': {
  headers['content-type'] = headers['content-type'] || 'application/json';
  if (!body.json) return undefined;
  let text = body.json;
  try {
    text = decomment(text);
  } catch {
    // decomment can throw on some inputs; carry on with the original text
  }
  try {
    return JSON.parse(text);
  } catch {
    return text;
  }
}

Why it matters: a body that mixes comments with unquoted variables ("quantity": {{qty}}) still fails JSON.parse after the comments are stripped, so it takes the fallback path. Returning body.json there hands interpolate-vars a string that still contains //; axios' stringifySafely then fails to parse the interpolated result and JSON.stringifys it, so those requests stay double-encoded. Returning the decommented text makes the interpolated string valid JSON — which is effectively what the desktop app does, since it always sends decomment(json).

I compared the three variants by running the body builder against the decomment that ships with the desktop app (4.1.0), then applying variable interpolation and axios' stringifySafely rule:

body	5.0.2 today	fix as written above	fallback to decommented text	desktop 4.1.0
no comments	object	object	object	sent as-is
line comment	quoted string	object	object	sent as-is
comment on its own line	quoted string	object	object	sent as-is
/* */ block	quoted string	object	object	sent as-is
// inside a string value	quoted string	object	object	sent as-is
escaped quote in a string value	quoted string	object	object	sent as-is
unquoted {{var}} + comment	quoted string	quoted string	sent as-is	sent as-is
trailing comma left by commenting a field out	quoted string	quoted string	quoted string	quoted string
empty body	no body	no body	no body	quoted ""

The trailing-comma row is invalid JSON in every client, desktop included — that one is not something this fix should paper over.

Opening a PR with this.

[alanmdza]

Correction to the root cause in the description: prepareBody in ipc/network/prepare-request.ts is not the function that runs for a normal send. The body of a regular request is built by getRequestData in ipc/network/index.ts:

case 'json':
  return body.json || undefined;

The raw commented text becomes request.data, interpolateVars takes the string branch, and axios' stringifySafely quotes it. prepareBody is only reached when data is still undefined, so patching it alone changes nothing for a normal request — I confirmed this by patching the shipped 5.0.2 bundle: with only prepareBody fixed the request still went out double-encoded, and it was fixed once getRequestData stripped the comments.

Worth noting that getRequestData's own doc comment says "Similar to bruno-cli's prepare-request.js", which is exactly where the CLI applies decomment.

Also, and contrary to what I wrote in the description: decomment is not a dependency of this repo. script-runner.ts declares a local function with that name that currently returns the script untouched:

const decomment = (script: string): string => {
  if (!script) return '';
  return script;
};

So there is no comment stripping anywhere in the extension today. #138 fixes both call sites with a small dependency-free helper, to avoid adding the package and touching the lockfile.