Repository navigation
Replies: 2 comments
Episode 4: new release, familiar queue bug. Repair 2.4 for Codex VS Code 26.930.61225Codex has another update. I downloaded the official Windows x64 package, compared the shipped files, reran the regression suite, and prepared my fourth community patch. How many episodes until OpenAI joins the conversation? Grab some popcorn. 🍿 What actually improvedThe bundled CLI moved from 0.160.0 to 0.160.1. There is a useful fix: preserving Official change: #51121 Other observed changes include build metadata, a CLI version string, and analytics grouping of And the follow-up queue?It survived the update. So did the defects.
Some bundle filenames changed. The reviewed queue logic did not. Controlled tests against the official code still reproduce:
Consistency is good. I was hoping for a different kind of consistency. Tests and results
That is 242 successful check executions, not 242 distinct scenarios. The canonical suite includes negative controls that pass when they reproduce an original defect, alongside repair, compatibility, and packaging checks. These totals do not mean the official extension is fixed. Coverage includes concurrent writers, two windows across 180 cycles and three seeds, CAS retries, stale snapshots, removals and Undo generations, identical text under distinct IDs, interrupt/resume cases, dead-owner recovery, process death during lock preparation, and server queue integration. The CLI checks use a real app-server with a local synthetic provider and an isolated home, without production model calls. The finished package accounts for all 19,378 original archive entries, modifies only six declared entries, and adds six repair/backup entries. No files are missing. The official CLI and unrelated entries are hash-verified. Packaged and installed host startup checks passed in Node and Electron. And yes, there is a negative startup test for the wrong Fourth patch: repair 2.4Target: Codex VS Code extension 26.930.61225, Windows x64. The repair uses a separate atomic journal with revisions and compare-and-set retries, so stale Memento snapshots cannot replace the authoritative queue and competing writers cannot silently overwrite each other's changes. It retains the existing coordinator and the official CLI 0.160.1. The public download contains repair sources, tests, and an installer that downloads and verifies the official extension before building locally. It contains no personal settings, saved conversations, credentials, or redistributed official extension bundles. Download and technical report: https://github.com/IveSan83/codex-vscode-queue-repair/releases/tag/v2.4.0 Source: https://github.com/IveSan83/codex-vscode-queue-repair Ongoing investigation: #50980 Previous patches: 2.1 for 26.930.31428, 2.2 for 26.930.31730, 2.3 for 26.930.51102. The new patch is installed and active locally. The initial post-restart log sample contains no send-lock, undefined-JSON, or journal errors. That is an initial live check, not comprehensive UI certification. WSL flicker, Remote SSH lifecycle issues, Desktop command stalls, and older-CPU crashes are separate reports and are not claimed fixed by this patch. OpenAI, we can wrap up the series nowTibo announced 28 days of improvements or a full usage-limit reset: https://x.com/thsottiaux/status/2106845241357824205 Here is a candidate for an improvement of the day: fixing this queue. The reproduction, regression suite, and patch are ready for review. As for me, I think a lifetime supply of usage resets would be fair. Or at least the head of QA's salary. I have been doing community QA for OpenAI for almost a week; we just need to sort out the employment paperwork. 😄 Which arrives first: an official fix, a maintainer reply, or community patch number five? To be continued. Keep the popcorn handy. 🍿 Search terms: Codex VS Code queue fix, disappearing messages, duplicate follow-ups, stuck sending, Memento race, undefined is not valid JSON, 26.930.61225. |
Independent review of the original public receipt patch — archived researchThis review concerns v1 for 26.930.21537. The author has since published v2 and explicitly acknowledges that the queue-storage races remain unresolved. His v2 has not yet been independently rerun on our harness. This copy preserves the original technical findings after moving my comments out of his issue at his request. @VitalOverdose Bro, I downloaded your patch, took it apart, and ran it through an independent test harness. Thanks for sharing the implementation and being explicit about its limitations. I verified all six packaged checksums, reconstructed your patched Your durable receipt approach has a useful core: exact thread ID + client-message ID receipts survive a restart and the original ten-minute protection window, while preserving a new message with identical text. I confirmed cross-host receipt visibility, filtering of delivered entries, reconciliation against exact accepted IDs, and four real processes concurrently writing matching receipts. However, keeping queue persistence in Memento and filtering delivered IDs does not cover the following cases, which I reproduced:
I ran 19 scenarios in Node and the same 19 in VS Code's Electron. All assertions passed, including the four scenarios deliberately asserting these limitations. That is 38 independent test executions, not a rerun of your original 25 checks: their source is not included in the review package. The stale-snapshot and competing-writer cases use the actual patched host class with controlled storage. They model Memento behavior; they do not execute VS Code's internal Memento implementation or its live panel. For comparison, my revisioned-journal/CAS implementation preserves both additions in the common-revision case and retains an undelivered entry when legacy Memento receives an empty snapshot: I think durable exact-ID receipts are a useful additional replay defense. Queue consistency still needs its own solution, and receipt persistence needs a release/error-handling path that cannot strand the active lock. Neither approach should claim exactly-once external execution when delivery is uncertain. Regression testing is essential here: delivered-message replay, undelivered-message loss, concurrent queue writers, restart, and filesystem failures need separate cases. Four processes safely publishing receipt files is useful evidence, but queue-state synchronization needs to be tested separately too. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Codex VS Code queue regression: investigation, reproducible tests and version-specific patches
Maintained by IveSan83. Latest published patch: v2.4.0 for extension 26.930.61225, Windows x64.
This is the central thread for my investigation, community patch releases, and test results. Release announcements and further analysis will be kept here.
Symptoms and reproduction
Start a new Codex chat and send
What is 2+2?. While the response is running, sendAnd 3+3?, followed by another short message. Reported symptoms include disappearing follow-ups, a saved message remaining above the composer, subsequent messages blocked behind it, indefinite Thinking/sending, and already accepted messages returning after restart. The live occurrence is intermittent; the controlled regression cases reproduce the underlying paths separately.Test ordinary completion, follow-ups during execution, Queue/Steer/Interrupt, Stop with pending follow-ups, restart, two windows, and identical text under a new client-message ID as separate scenarios. Do not automatically retry a message whose delivery is uncertain: verify conversation history first.
Error signatures and search terms from the reports
The following are collected diagnostic/search terms, not proof that every occurrence has the same cause:
Failed to release queued message send lock"undefined" is not valid JSON/SyntaxError: "undefined" is not valid JSONDelivery could not be confirmed. Check the conversation before deleting this saved messageQueue paused because you interruptedQueued follow-up changed before dispatchsubmission-outcome-unknownSeparately reported issues outside this queue repair:
403 cloudflare_challengeon/transcribe, WSL sidebar refresh/flicker, missing approval controls, Remote SSH app-server socket conflicts, Desktopexec_commandstalls, and native crashes on older CPUs. They are included for diagnostic context; the queue patch does not claim to fix them.What the tests establish
The original shipped code still reproduces undelivered-message loss on empty storage refresh, restored-pending replay despite acceptance evidence, and undefined JSON after lock release. For 26.930.61225,
out/extension.jsis byte-identical to 51102; all 68 reviewed queue-coordinator members match after identifier normalization. Structural comparisons are limited to the inspected components.The canonical suite passes 94/94 in Node and 94/94 in Electron, including negative controls reproducing the official defects. CLI 0.160.1 passes 16/16 isolated protocol checks. An independent review of the original third-party receipt patch adds 19 checks per runtime. Combined: 242 check executions, not 242 distinct scenarios. Headless tests and initial live logs are not exhaustive UI/model certification.
The repair uses a separate atomic revisioned journal, compare-and-set retries, canonical owner/follower state, exact-ID acceptance checks, retired generations, verified dead-owner recovery, and valid JSON null for void bridge responses. No exactly-once external side-effect guarantee or faster model generation is claimed.
October 6 update: Fourth patch released for 26.930.61225. The host is byte-identical to 51102, and the reviewed queue components still match. CLI 0.160.1 fixes remote Windows MCP environment propagation, not queue persistence. Full new inspection and tests: #50980 (comment)
How many more Codex VS Code releases will carry the same queue state bug? I am now on my fourth published repair release.
The short version
Follow-up messages can disappear, remain pending, or be submitted again after they have already been accepted. Reports cover Windows and macOS. This is more than a cosmetic spinner problem: users need to know whether their instructions were actually delivered.
The affected queue still relies on shared extension-state snapshots. A stale snapshot can replace newer queue state, losing a new message or restoring an already submitted one. Separately, a restored
pendingentry can be dispatched again despite a positive acceptance receipt. There is also an internal response-contract defect: send-lock release returnsundefined, which the bridge serializes into a response that the frontend JSON parser rejects. That parsing error alone does not prove that the underlying lock remained held.Research and reproductions
The reviewed coordinator, submission preparation function, queue adapter and host storage class match across 31730 → 41038 → 51102 → 61225 after normalization of minified identifiers. All 68 coordinator members match. This comparison is limited to those components, not the entire extension or all external dependencies.
Four published repair releases
The current repair uses a separate revisioned queue journal, compare-and-set writes, canonical owner/follower confirmation, acceptance checks by message ID, stale-message retirement and recovery after verified writer process death. It preserves the upstream app-server queue.
Latest results: 94/94 tests in Node and 94/94 in VS Code's Electron — 188 passes, zero failures, skips or cancellations. Each runtime also completes 180 two-window add/read/remove cycles with concurrent writes: zero lost messages, zero resurrected messages and zero incorrect reads.
Repeated testing caught a defect in my repair too: transient Windows
EPERMwhile inspecting a competing lock owner's metadata. I fixed it and added three deterministic tests. Live/unverifiable owners remain protected, and persistent denial does not modify the journal. The release includes sanitized TAP logs, checksums, component comparisons and the completed VSIX inventory/startup audit. These are headless code/filesystem checks with controlled transport, not exhaustive live UI/model testing.A request to the maintainers
As of October 5, 2026, I have not found a public maintainer response in the linked queue reports; the automated duplicate-detection reply is not a technical response. Meanwhile, the same affected components remain in successive builds. From the outside, it looks like this regression keeps shipping without the necessary coverage.
Please take the patch, review it, and integrate a proper upstream fix. Or ask your own AI model to do the integration and run the regression tests — the implementation and reproducible evidence are already here.
The series continues. I will post further findings and patch updates here and keep this opening post current. Subscribe if you want to follow along; hopefully the next episode will be an upstream fix :)
— IveSan83
Search terms / error signatures
Codex VS Code extension queue fix; openai.chatgpt follow-up queue bug; messages disappearing; prompts stuck pending; follow-up spinner; duplicate prompts after restart; queue state race condition; stale Memento snapshot; queued messages not sending; queue / steer / interrupt; Windows multi-window queue synchronization;
Failed to release queued message send lock;"undefined" is not valid JSON;Queued follow-up changed before dispatch;submission-outcome-unknown.Patched targets: 26.930.31428, 26.930.31730, 26.930.51102, 26.930.61225 — Windows x64. The 26.930.41038 build was reviewed for comparison; these packages do not claim installation support for it.
#Codex #VSCode #QueueBug #MessageLoss #RaceCondition #BugFix
Consolidated independent receipt-patch review
#50980 (comment)
Please use this discussion for feedback on my patches and release announcements. Other authors’ threads should remain focused on their implementations.
All reactions