WikifitaGitHub live67e8de5
pesquisa · openai-research/vendor-analysis

Análise de Vendors — OmniRoute, openai-oauth e pi-ai

What each open source solution gets right, the errors that cause bans, and why none knows the critical mechanisms

Baixar raw

Análise de Vendors — OmniRoute, openai-oauth e pi-ai

Part of openai-research. The first two were vendored into the harness for study (vendor/OmniRoute, vendor/openai-oauth); o pi-ai já é dependência do Harness.

openai-oauth (EvanZhouDev) — Apache-2.0

What it gets right: OAuth PKCE fiel ao Codex CLI (client público, :1455, codex_cli_simplified_flow); bridge Codex→OpenAI-compatível (streaming-only simulado, model catalog, responses-lite); extensão de browser minimalista (declarativeNetRequest captura o redirect e devolve via postMessage — sem servidor).

Gaps vs the primary source:

  • Does not implement the X-OAI-IS (nem precisa pro seu escopo — só fala com o backend codex)
  • Não conhece link-session, sentinel web, conduit
  • Sem multi-conta (o Auth0 invalida o refresh_token family sem prompt: login)
  • Refresh proativo 55min (o codex-rs usa janela de 5min antes do exp)

OmniRoute (diegosouzapw) — MIT

What it gets right: multi-conta Codex com prompt: "login" (a chave anti session-takeover do Auth0); leitura completa dos headers de quota (x-codex-primary/secondary-*); fingerprint de cliente (UA, wreq-js); família inteira de executores -web para dezenas de providers.

Material errors (cause bans):

  • Wrong proof-of-work: uses SHA3-512; the real chat submode solver is FNV-1a 32-bit with murmur finalization (source: desktop renderer)
  • Não implementa a cadeia X-OAI-IS — usa cookies de browser real (Playwright/CDP), que mascaram o problema até o risk score escalar
  • Não conhece conduit token (x-conduit-token), link-session, nem o protocolo f/* atual
  • Turnstile (dx VM payload) não implementado

pi-ai (@earendil-works) — dependência do Harness

What it gets right: provider openai-codex completo — OAuth PKCE + device-code, baseUrl chatgpt.com/backend-api, protocolo openai-codex-responses com WebSocket (responses_websockets, connection reuse, delta requests, fallback SSE), catálogo gerado, efforts none→max. É a base mais sólida dos três para o flow Codex.

Gaps: nada do submodo chat (sentinel/conduit/X-OAI-IS/link-session); The model listing UX does not match the app behavior.

Runtime mechanics observed 2026-08-26 (what the vendors actually run)

  • OmniRoute chatgpt-web-codex executor: ChatGptBrowserWorker — needs a real Chromium/Chrome (/usr/bin/chromium, chromium-browser), browser login state (browser session storage), ensureConnectionStorageStateFromCredential (reads the credential's browser storage), a tunnel client, then bridgeToResponsesSSE (translates web SSE → Responses SSE). It does not implement the desktop's attestation/challenge; everything rides the web session (site cookies + browser session) of the real account.
  • openai-oauth v2: pure-OAuth (Sign in with ChatGPT / device code), client adapters (AI SDK / OpenAI client / compatible), models gpt-5.6-terra, gpt-5.6-sol, image gen, Responses transport with baseURL — no browser session, no cookies, no PoW. Same auth family as the desktop (public client app_EMoamEEZ73f0CkXaXp7hrann) — the version-independent marker of the "chatgpt account" route.
  • The desktop reference: Bearer Codex + DeviceCheck + originator: Codex Desktop + UA Codex Desktop/<build> (Mac OS; arm64) (see user-agents).

The ban hypothesis (why OmniRoute web users reportedly get banned)

Facts vs hypothesis:

  • Fact: the web route is sentinel-protected (fingerprint + PoW). OmniRoute solves SHA3-512 PoW (not the desktop's FNV-1a), builds its fingerprint from the scraped site (slots 5/6 = web deployment, unlike the desktop real-values run), and drives the session with a real browser whose storage belongs to the user's actual account.
  • Fact: the web session cookies + __oailb link-session are 1h-window derived-session artifacts (see auth-and-link-session); any replay through a proxy leaves the account's session timeline inconsistent with the browser's.
  • Hypothesis (consistent with reports): the sentinel signature of the OmniRoute requests (wrong hash family, hardcoded heap 4294705152 vs real heap, fixed UA list, browser-account + foreign request mix) is treated as a non-genuine web client — repeated hits raise the account's risk score; after enough contamination the web session is invalidated/limited (ban-like). The desktop flow does not share this surface (attestation + Codex Bearer, no cookies).

Consolidated state of the art

MecanismoOmniRouteopenai-oauthpi-aiNossa RE
OAuth PKCE Codex✓ (+prompt login)
Refresh preemptivoparcial55min5min window (codex-rs)
/responses + encrypted reasoning✓ (WS)
Sticky turn-state✓ mapeado (probe API; 0 no desktop — desktop usa o websocket)
/responses/compact✓ mapeado
PoW FNV-1a sentinel✗ (SHA3 errado)✓ validado
Cadeia X-OAI-ISnão observada nos fluxos executados (A/A1/manual — 0 ocorrências nos headers do main); fluxo B: desconhecida (não executado); Rust não capturado
Conduit token✓ mapeado
Link-session✓ validado
Voz realtime (WebRTC)parcial✓ mapeado
Tasks whamparcial✓ mapeado
Plugin runtime (primary)✓ mapeado (26.826.11250 on-demand)

No known public project implements the desktop integrity chain — the DeviceCheck registration (POST /devicecheck + _devicecheck cookie + __oailb web session) with the live app-server session token — nor the exact f/* turn cycle (challenge → prepare → conversation without the conduit header). That is the core area of the planned security report. (Earlier claims about an "X-OAI-IS chain" are not supported by the desktop capture — see the table above.)

Cross-references