Claude Code Usage: a released source fix and the still-open reporter’s Windows crash

#topic

Claude Code Usage: a released source fix and the still-open reporter’s Windows crash

Primary record, checked October 20, 2026. The September 29 issue #122 is a specific report from jordanvalnet, not a synthetic agent-generated ticket: VS Code extension v2.4.0 flooded its host with per-record unknown-model warnings; the reporter observed Windows renderer Section handles and system commit rising until crashes. The reporter supplied a CPU profile, system events, reproduction and disabling the extension as a workaround. The diagnostic measurements and broader causal attribution are the reporter’s observations, not independent replication. The automated first-pass DeepSeek comment explicitly says it is not a maintainer decision.

Patch before the report; account approval. A different contributor, rsyuzyov, had already opened PR #120 on September 28 to deduplicate unknown-model warnings, marked “Generated with Claude Code” and co-authored by Claude Opus 5.5. A red-green test checked per-model warning behavior; a bot raised changelog and lifetime-state questions. Carl723000 approved and merged on September 30, explicitly affirming override precedence and that merged code was not yet a published extension. The owner account’s approval/comment text is labeled generated with Codex: authority and responsibility to merge are visible, unaided human inspection time is not. Another requested reviewer remained awaiting.

Additional bounded patch, scoped native acceptance and exact release. The maintainer’s PR #124 on a Codex branch, with Codex co-author trailers, incorporates #120, explicit Opus 5.5 pricing and a lifetime budget for distinct unknown-model warnings, among numerous other refresh changes. Its initial draft called for native checks before merge while explicitly disavowing proof of the reporter’s Windows OOM fix; the public PR shows successful CI and merge October 3 but not a second code-owner approval. The October 5 v2.4.1 release credits #120 and #124, says a local installed run passed, and explicitly lists other native acceptance/reviews waived, not done; Windows Section-handle/commit-memory validation still belonged to the affected user. Release prose was generated with Codex, but the account published it. In #122, a Carl723000-account, Codex-generated October 5 comment requests that jordanvalnet install v2.4.1 and check warnings, handle growth and crashes. No reporter reply is visible as of October 20, and #122 stays open. v2.5.0 appeared October 15 retaining the source fix; another Codex-generated first-pass comment on the maintainer account again invites a reporter retest but disclaims being a maintainer decision. Do not turn a source fix or release into a reporter-confirmed fix for the Windows crash.

Same repository, contrasting disposition. In issue #126, another user, mkgaskin-ops, supplies a local reproduction and self-applied patch for an argument-stack overflow on large histories, a separate failure mode observed on v2.3.2. The Codex-assisted PR #131 entered v2.5.0 with a reported 150,000-record regression. On October 15 Carl723000’s account closed that specific issue with a reopen invitation, after an explicitly Codex-generated first-pass comment; no post-release reporter retest is recorded. The two statuses reflect different scopes and owner actions: one Windows-native end-state left open for its user, one code-path defect closed after a release and internal checks. Neither is an independently requester-confirmed success. Do not treat the positive pre-release candidate-test note in #131 as a retest of either reporter’s released version.

What this changes. This is a public reporter→Claude-assisted patch→Codex-assisted merge/release→explicit request for reporter verification within one product, but not a full accepted chain. The October 15 invitation itself is a generated first pass; the durable signal is that #122 remains open across two releases while #126 was closed by a maintainer-account action. It illustrates how support/engineering can preserve an unresolved user oracle through shipping, without proving the fix failed, customer never tested privately, or the workflow generalizes. Next check #122 for an original-reporter version-numbered Windows retest; only then bind result to that claim. Active human hours, model bill, control group and 30-day repeat contacts are absent. Links: requester-search brief, disposition, field owner, request ledger.