Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: Intermittent canonical OpenAI synthetic 429 upstream_reset_replay_refused on v2.91.0; request safe transport mitigation

Open
  • Is something wrong?
#7,720 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
node.js, typescript
Domain
backend, networking

Research direction

Inspect OpenCodex's upstream HTTP/SSE transport handling for canonical OpenAI forwarding where upstream_reset_replay_refused is generated; correlate ~/.opencodex/usage.jsonl timestamps with proxy logs. Verify providers.openai.upstreamWebsocket state and capture attempts.failureStage on next occurrence to locate reset stage.

Written by the indexing model from the issue text.

Description

bug streaming
Client or integration

Codex App (macOS), using OpenCodex's canonical OpenAI / Codex-login route.

Area

Proxy / routing — upstream HTTP/SSE transport, connection-reset handling, synthetic 429 diagnostics.

Summary

Intermittent GPT turns fail in Codex App with exceeded retry limit, last status: 429 Too Many Requests. OpenCodex's own usage log identifies these not as an upstream quota rate_limit_exceeded, but as locally generated HTTP 429 responses with errorCode=upstream_reset_replay_refused and:

The upstream exchange did not complete reliably. The request may already have been processed; automatic replay was stopped.

The workflow was stable for months before recurrent failures in October 2026. The local custom model-router on port 10101 has been stopped and removed from Codex global routing; the active entrypoint is the OpenCodex proxy on 127.0.0.1:10100. The failures persisted after upgrading OpenCodex to v2.91.0. An operator check on Oct 25 confirmed providers.openai.upstreamWebsocket=false (HTTP/SSE selected); the exact transport state at each prior log timestamp was not independently recorded.

This report requests better transport attribution and an actionable, safe mitigation. It does not request blindly replaying an ambiguous request that may already have been processed.

Reproduction

Intermittent; not yet a deterministic minimal reproduction.

  1. Start Codex App with OpenCodex v2.91.0 routing official GPT models via the canonical openai (Codex login) provider.
  2. Use GPT-6 Sol or GPT-6.1 Sol in ordinary long-running Codex project turns.
  3. Some requests stop and Codex displays exceeded retry limit, last status: 429 Too Many Requests.
  4. Correlate the time with ~/.opencodex/usage.jsonl. status=429, errorCode=upstream_reset_replay_refused, and the above upstreamError are logged.
Version
  • OpenCodex: v2.91.0 (latest explicitly verified locally at time of report).
  • Codex desktop app bundle: 26.1016.62342.
  • Separately installed terminal Codex CLI: 0.144.1 (not asserted to be the App's bundled runtime).
  • Prior duplicate npm CLI 0.142.4 removed; it did not resolve the issue.
Operating system

macOS. Exact OS build/architecture not collected in the sanitized diagnostics.

Provider and model

Canonical openai / Codex login, gpt-6-sol and gpt-6.1-sol. No API credential information shared.

Logs or error output

Redacted examples from the local usage log, times in UTC+08:00:

Local time Provider/model status errorCode durationMs
2026-10-23 18:59:36 openai / gpt-6-sol 429 upstream_reset_replay_refused 1103
2026-10-23 18:59:46 openai / gpt-6-sol 429 upstream_reset_replay_refused 1034
2026-10-23 19:00:00 openai / gpt-6-sol 429 upstream_reset_replay_refused 885
2026-10-23 20:23:43 openai / gpt-6.1-sol 429 upstream_reset_replay_refused 5131
2026-10-23 21:48:39 openai / gpt-6.1-sol 429 upstream_reset_replay_refused 5215
2026-10-24 11:31:54 openai / gpt-6-sol 429 upstream_reset_replay_refused 5228

Distinct issue: two MiniMax-M2.7 429s in this log were genuinely returned by the MiniMax provider, with an explicit Token Plan usage-limit message. Those should not be conflated with the synthetic OpenAI-route 429s above.

Redacted configuration
  • Codex's root openai_base_url pointed to http://127.0.0.1:10100/v1 during the current OpenCodex-integrated setup.
  • Previously installed custom local proxy 127.0.0.1:10101 is no longer listening or configured in the root Codex path.
  • providers.openai.upstreamWebsocket=false verified on Oct 25; no claim that this was recorded at each earlier event.
  • No auth tokens, emails, cookies, account IDs, request bodies, local project names/paths, or full logs included.
Expected behavior

Stable canonical OpenAI forwarding, or precise stage-level diagnostics and a safe mitigation if an ambiguous upstream reset occurs. A proxy-local safety refusal should be distinguishable from upstream rate limiting in user-facing errors and account health tracking.

Questions for maintainers
  1. On v2.91.0 with HTTP/SSE, which exact upstream transport stages can produce upstream_reset_replay_refused for canonical OpenAI forwarding? Does the code distinguish an upstream idle-socket reuse/reset from TLS/proxy failures or an upstream response?
  2. Are there verified connection-pool or pre-send transport mitigations that preserve the OpenCodex graphical multi-provider model picker, without unsafe duplicate sends?
  3. Is there a version/PR after v2.91.0 that actually fixes the underlying connection reset, as opposed to changing the classification or retry decision?
  4. Which sanitized fields should be captured for the next occurrence (attempts.failureStage, failureCause, transportPhase, sendCount, resendPermission, upstream headers, requestId) to confirm root cause?
Checks
  • Searched existing issues (including #6658, #6510, #919 and #7073).
  • Removed secrets, credentials, request bodies, private paths and account identifiers.
  • Did not claim that the upstream OpenAI service itself sent the synthetic 429.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
9h 39m
Merged PRs (30d)
633

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.