What version of the IDE extension are you using?
openai.chatgpt 26.928.31416 (linux-x64)
What subscription do you have?
Not collected in this report.
Which IDE are you using?
VS Code.
What platform is your computer?
Linux x64.
What issue are you seeing?
The VS Code internal fetch bridge serializes an undefined handler result using JSON.stringify(o). This produces undefined rather than JSON text. The webview success handler subsequently calls JSON.parse(e.bodyJsonString) and rejects an otherwise successful request.
This is observed when releasing a queued follow-up send lock. Sanitized logs from October 1, 2026 (local time, UTC+8):
10:35:28.203 [warning] Failed to release queued message send lock
conversationId=<redacted>
errorMessage="\"undefined\" is not valid JSON"
errorName=SyntaxError
at JSON.parse (<anonymous>)
at e.onFetchResponse (.../webview/assets/app-initial-4bd9e54bcd58.js:3:1518)
10:45:29.373 [warning] Failed to release queued message send lock
conversationId=<same-thread-redacted>
errorMessage="\"undefined\" is not valid JSON"
errorName=SyntaxError
The user also observed a message being processed twice without intentionally sending it twice. In the local rollout, the same user text appears as two distinct user response items at:
- 2026-10-01T02:35:28.156Z
- 2026-10-01T02:45:29.271Z
These are separate message occurrences, not the normal response_item/event_msg pair for a single message.
The parsing defect is confirmed; its causal relationship to the duplicate submission is not established. The lock release handler performs its side effect before returning undefined, so the warning alone does not prove that the actual lock was not released.
What steps can reproduce the bug?
The exact UI sequence for the duplicate submission has not yet been reduced to a deterministic reproduction. The serialization failure can be reproduced independently:
const assert = require("node:assert/strict");
const handlerResult = undefined; // e.g. queued-follow-up-send-lock-release
const response = {
responseType: "success",
status: 200,
bodyJsonString: JSON.stringify(handlerResult),
};
// The success response has no "body" property:
assert.throws(() => JSON.parse(response.bodyJsonString), SyntaxError);
Inspection of the installed bundle found:
queued-follow-up-send-lock-release calls this.queuedFollowUpSendLocks.release(...) without returning a value.
- The internal VS Code fetch bridge returns
bodyJsonString: JSON.stringify(o).
- The webview success handler uses
"body" in e ? e.body : JSON.parse(e.bodyJsonString).
What is the expected behavior?
Successful internal requests with no return value should resolve without a JSON parsing error. Queued messages should be processed once, with successful submissions removed from the queue.
Additional information
A local workaround changed only the internal bridge serialization expression:
- bodyJsonString: JSON.stringify(o)
+ bodyJsonString: JSON.stringify(o ?? null)
Validation:
- Reproduced the original undefined parsing failure.
- Checked round trips for undefined, null, an object, false, 0, an empty string, an empty array, and an acquired=false object (8 cases).
node --check passed for the modified bundle.
- Verified the installed file differs from its backup only by the intended expression.
This is a local installed-bundle workaround, not an upstream source patch. End-to-end verification after reloading VS Code, including whether duplicate messages stop, is still pending.
Potential investigation lead, not a confirmed cause: the installed send-lock implementation retains sent-message IDs for 6e5 milliseconds (10 minutes), close to the observed 601-second gap. This does not establish that both submissions used the same client message ID.
Logs and code were inspected with assistance from Codex. Local paths and conversation identifiers are redacted.
What version of the IDE extension are you using?
openai.chatgpt 26.928.31416(linux-x64)What subscription do you have?
Not collected in this report.
Which IDE are you using?
VS Code.
What platform is your computer?
Linux x64.
What issue are you seeing?
The VS Code internal fetch bridge serializes an undefined handler result using
JSON.stringify(o). This produces undefined rather than JSON text. The webview success handler subsequently callsJSON.parse(e.bodyJsonString)and rejects an otherwise successful request.This is observed when releasing a queued follow-up send lock. Sanitized logs from October 1, 2026 (local time, UTC+8):
The user also observed a message being processed twice without intentionally sending it twice. In the local rollout, the same user text appears as two distinct user response items at:
These are separate message occurrences, not the normal response_item/event_msg pair for a single message.
The parsing defect is confirmed; its causal relationship to the duplicate submission is not established. The lock release handler performs its side effect before returning undefined, so the warning alone does not prove that the actual lock was not released.
What steps can reproduce the bug?
The exact UI sequence for the duplicate submission has not yet been reduced to a deterministic reproduction. The serialization failure can be reproduced independently:
Inspection of the installed bundle found:
queued-follow-up-send-lock-releasecallsthis.queuedFollowUpSendLocks.release(...)without returning a value.bodyJsonString: JSON.stringify(o)."body" in e ? e.body : JSON.parse(e.bodyJsonString).What is the expected behavior?
Successful internal requests with no return value should resolve without a JSON parsing error. Queued messages should be processed once, with successful submissions removed from the queue.
Additional information
A local workaround changed only the internal bridge serialization expression:
Validation:
node --checkpassed for the modified bundle.This is a local installed-bundle workaround, not an upstream source patch. End-to-end verification after reloading VS Code, including whether duplicate messages stop, is still pending.
Potential investigation lead, not a confirmed cause: the installed send-lock implementation retains sent-message IDs for
6e5milliseconds (10 minutes), close to the observed 601-second gap. This does not establish that both submissions used the same client message ID.Logs and code were inspected with assistance from Codex. Local paths and conversation identifiers are redacted.