Skip to content

Tracking: release queue, security review, and open blockers #755

Description

@lidge-jun

Where the queue stands after a full triage pass, and what has to happen before the next release. Every claim here was measured against dev rather than read off the PR list — merge status came from git merge-tree against the current head, not from GitHub's mergeable field, which reads UNKNOWN for most of these.

Current state

dev CI is green across all six jobs. It had been red on every job; the baseline breakage was six GUI build type errors and fourteen stale GUI tests, all fixed and pushed. main is now an ancestor of dev, so the next promotion is a real fast-forward rather than a merge.

Two release blockers landed: #702 (expired forward continuations now fail closed instead of silently dropping context) and #720 (a replacement proxy arriving at the readiness deadline is no longer misreported as a restart failure).

One thing to know when reading CI on your PR: windows-latest occasionally panics inside Bun 1.3.14 itself — a timer-heap assertion reached through spawnSync with a timeout, triggered by our Windows ACL hardening. It is intermittent and unrelated to any PR. The upstream fix is merged in Bun main but there is no stable release carrying it yet.

Merge queue

Order matters for the first two; the rest are independent.

# PR Why here
1 #671 exact account routing Security review, then merge. Must precede #715
2 #715 account pool priority Rebases onto #671
3 #616 hosted image tool preferences Unblocked today, ready
4 #610 catalog probe caching Ready
5 #736 Windows scheduler status Ready
6 #752 tray socket isolation Security review + Windows CI
7 #743 discovery contract Security review
8 #750 pool plan persistence Security review, still draft

Why #671 before #715. These look like rivals for the same subsystem and are not. #715 filters already-eligible accounts into priority tiers; #671's qualified selector never reaches that path, because the resolution in src/codex/auth-context.ts short-circuits on fixedAccountId !== undefined before pool selection is consulted. So priority can never contend with an exact binding. Landing #715 first would mean rebasing it twice. When #715 rebases, it needs one combined regression: priorities and a pin pointing at account B, a request bound to account A, asserting A is used and neither the active nor pinned account moves.

#616 was fixed by 1aba0e4b3 and left sitting under a CHANGES_REQUESTED filed 32 minutes earlier. That review is dismissed; the PR is ready for a maintainer to verify and merge.

#610 stops repeated codex --version probing, but does not reorder the catalog cache lookup ahead of runtime resolution — the cache key is derived from the resolved runtime, so it structurally cannot. Merge the PR, keep #606 open pending Windows timing re-measurement.

Security review queue

MAINTAINERS.md:33-34 requires explicit review for these. What each reviewer should actually be looking at:

#707 needs splitting before it can be reviewed responsibly. It is 7,252 lines containing six independent threat models: service token transactions, ownership-manifest locking, management route gating plus outbound proxy policy, npm PATH hardening, browser anti-framing, and a CI timeout matrix. A single approval on that diff implicitly covers work the approver may not have read. Each seam already has its own implementation and test files. The CI timeout change is not a security change at all and can land on its own today.

Changes requested

Formal reviews are on each PR; the detail is in the per-PR comments.

On presets specifically: when the evidence is incomplete, the same clause prefers an inert src/providers/free-directory.ts row over a canonical registry entry. hyperbolic, deepinfra and novita already have rows there. The fallback is not "drop the work".

Closed

#687 (WorkBuddy) — closed on licensing, not code. Their AUP requires express prior written permission for external interoperability components. The implementation was careful; we are simply not authorized to ship or maintain it.

#533 stays open until #557 merges, at which point it closes as superseded with attribution intact. range-diff confirms #557 contains all fourteen of its commits plus two.

Issues

Zero of the 39 open issues were closeable. Each was re-checked against dev with a file and line showing where the defect still lives. Several are waiting on a PR in the queue above rather than on new work: #722 on #736, #721 on #734, #724 on #750, #733 on #752, #606 on #610 partially, #723 on #744 partially.

Worth naming as a near-miss: ee3eaa2c0 added UTF-16 scheduler XML decoding and is on dev, which looks like it closes #722. It decodes a different surface than the localized status table the issue reports, and src/service.ts still prints that table verbatim. Closing on that commit would have been wrong.

Blocking the release

I will keep this updated as the queue moves.

Metadata

Metadata

Assignees

No one assigned

    Labels

    roadmapAccepted long-term work item; needs its own project cycle

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions