Request permission to submit a small stacked fix series for turn progression and interrupted-stream recovery #17428

I am respecting the current contribution policy and not opening an unsolicited PR.

While maintaining a private Codex fork, I isolated a small set of generic runtime defects and re-extracted them into reviewable slices on top of the current upstream release baseline, rust-v0.120.0 (65319eb).

These fixes are currently deployed in our fork, but the upstream-ready slices have already been trimmed to remove plugin-specific behavior, timeout-policy changes, and log-only investigative telemetry. What remains is a small stacked series of runtime correctness fixes.

I would like maintainer guidance on whether these are in scope for invited PRs.

Why I think this is worth upstream review

These are not fork-preference patches. They are narrow runtime behavior fixes that affect generic Codex turn handling and retry behavior:

1. explicit-only plugin/orchestrator routing is preserved correctly
2. tool output can trigger the next follow-up request without waiting for a stale response.completed
3. interrupted commentary-heavy streams stop being treated as substantive progress and stop looping misleadingly
4. websocket retries preserve partial response state when possible and fall back cleanly when partial resume is rejected

The slices are small, already separated, and validated on the current upstream release baseline rather than an older fork point.

Proposed stacked series

1. explicit-only routing
2. tool-output follow-up preemption
3. no-progress retry handling for interrupted commentary-heavy streams
4. websocket partial-response recovery

I have refreshed local branches for all four slices and can push them to a public fork immediately if maintainers think this direction is in scope.

Validation already completed locally

Release baseline:

• rust-v0.120.0
• commit 65319eb

Validation:

• Slice 1
  • cargo test -p codex-core-skills -- --nocapture
  • cargo test -p codex-core --test plain_text_mentions -- --nocapture
  • passed
• Slice 2
  • cargo test -p codex-core pending_input -- --nocapture
  • passed
• Slice 3
  • cargo test -p codex-core stream_no_completed -- --nocapture
  • passed
• Slice 4
  • cargo test -p codex-core client_websockets -- --nocapture
  • cargo test -p codex-core stream_no_completed -- --nocapture
  • passed

What I am explicitly not trying to upstream in this first series

I intentionally left out the policy-heavy and diagnostic-heavy parts of the private fork:

• default stream idle timeout reduction
• early websocket-stall fallback-to-HTTP policy changes
• transport and retry log amplification that was only useful during diagnosis

Related existing issues

This proposal overlaps with, but does not fully duplicate, some existing issues:

• TUI can get stuck with 'Messages to be submitted after next tool call' when sending during active output #15842
• Error: stream disconnected before completion: stream closed before response.completed #9995
• bug: WebSocket transport disconnects are handled as fatal termination with multiple abrupt disconnect paths #13949
• Incomplete stream can drop custom tool outputs and break thread resume #16255

If maintainers would rather anchor discussion on one of those existing issues instead of a new umbrella issue, I am happy to move there.

Specific ask

Would the team be open to inviting a stacked PR series for these slices, assuming the pushed branches match the descriptions above?

If not, I would still appreciate guidance on whether one of the four slices is clearly aligned enough to discuss further in a dedicated issue.