Repository navigation
Queue repair 2.3 - Codex 26.930.51102, Windows x64
Queue repair 2.3 — Codex VS Code 26.930.51102, Windows x64
This is the third published release of the independent queue repair.
Download
codex-vscode-queue-repair-2.3.0.zip: sources, builder and installer. The builder downloads the checksum-pinned official Windows x64 VSIX and applies the repair locally.codex-vscode-queue-test-results-2.3.0.zip: sanitized Node/Electron TAP logs, verification summary, package audit, component comparison and detailed investigation.SHA256SUMS-2.3.0.txt: archive checksums.
Extract the source ZIP and run START.cmd. Requirements: Windows x64, VS Code, Node.js and Python. Close all VS Code windows and reopen after installation. The package contains no account credentials, personal settings or machine-specific absolute paths. Author: IveSan83 (Eugene Bondarenko).
What the latest official build still reproduces
Controlled tests executing the actual shipped 51102 coordinator and response parser reproduce:
- A queued message disappears after an empty storage refresh representing stale snapshot delivery.
- A restored pending message is submitted again even when the controlled receipt lookup says it was already accepted.
- The send-lock release handler performs release and returns undefined. Serializing that result without a null fallback produces a response rejected by the frontend parser.
The third finding is a response-contract defect; it does not prove that the underlying lock stayed held or that it alone caused all delivery failures.
The coordinator, submission preparation function, queue adapter and host storage class match across official 31730, 41038 and 51102 after normalization of minified identifiers. All 68 coordinator members match. This is a comparison of the reviewed components, not a claim that the entire extension or all external dependencies are unchanged. The Windows native runtime remains CLI 0.160.0.
Repair-side improvement found during repeated testing
An earlier 91-test run passed in both runtimes. A repeated run exposed transient Windows EPERM while inspecting a competing writer's UUID owner file; the two-window stress case failed in both runtimes. Repair 2.3 adds bounded retries for owner metadata inspection. Live or unverifiable owners remain protected; persistent denial fails closed without changing the journal. Three deterministic fault-injection checks cover this behavior.
Final verification
- 94/94 Node tests and 94/94 Electron tests: 188 passes, zero failures, skips or cancellations.
- 180 two-window add/read/remove cycles per runtime: zero lost messages, zero resurrected messages, zero incorrect reads.
- Tests cover concurrent writers, stale snapshots, accepted-message replay, interruption and reload, identical-text messages with different IDs, removal/restore generations, owner/follower confirmation, real writer crashes and lock recovery.
- Three compatibility checks preserve upstream app-server receipt removal, owner/follower boundaries and subscription replacement cleanup.
- Cloud-history completion and plugin pagination checks execute current shipped functions.
- Finished VSIX inventory: 19,378 original entries, 19,384 packaged entries, 19,372 unchanged entries. No missing or unexpected files.
- Host storage startup and isolated journal read/write passed from both the completed VSIX and installed files in Node and Electron. Helper filenames and all modified-file hashes were verified.
- Following a manual VS Code restart, the running native process points to the repaired 51102 installation; installed hashes match and the observed startup log contains no undefined-JSON, send-lock-release, missing-module or unknown-queue-write errors.
These are headless code/filesystem tests with controlled transport. The brief restart observation is not a full live UI/model regression test. Cloudflare HTTP 403, unrelated metadata failures, MCP timeouts and ResizeObserver errors are outside this repair.