WikifitaGitHub live67e8de5
pesquisa · openai-research/flow-definitions

Flow Definitions — A / A0 / A1 / B (attestation vs PoW)

The definitive hierarchy of the ChatGPT Desktop flows — attestation (A, with A0 standalone and A1 session-keeper variants) and the untested sentinel/PoW path (B)

Baixar raw

Flow Definitions — A / A0 / A1 / B

Part of openai-research. Fixed vocabulary for the flows (validated 2026-08-27). Nomenclature: the flows are named by integrity mechanism, not by surface.

FLOW A — Device Attestation (Apple DeviceCheck)

The primary integrity mechanism of the desktop app on macOS (vPr() true — DeviceCheck addon, x-sentinel-dc → challenge → app_attest_challenge). Flow A describes who owns the session identity:

A0 — standalone (pure client)

The probe performs its own PKCE (browser authorize, OAuth exchange, session of its own) and uses the resulting access token as its identity. Valid by protocol, invalid for /f/conversation in practice — 27+ runs, all 403 "Unusual activity has been detected from your device". Root causes (each proven, see flow-a-403-cases): the oai-did must be the persisted installation one (never regenerated); the session must be the one created by the app-server login path (a manual authorize session is not recognized by the WAF); the conversation must NOT carry x-conduit-token. Until a fresh client can replicate the app-server login-session characteristics (golden item), A0 stays blocked.

A1 — session-keeper (the working one, 2026-08-27)

The probe uses the running app-server (the embedded codex process of the desktop app) as the keeper of the session identity — reached through the bezetacil harness (127.0.0.1:9228):

  • Access token: getAuthStatus {includeToken: true, refreshToken: false} → {"authMethod": "chatgpt", "authToken": "<eyJ…>", "requiresOpenaiAuth": true} — the live token of the app-server (NOT the static ~/.codex/auth.json, which can lag after the app-server refresh — a stale file access produced a burst of 403s).
  • oai-did: the live renderer localStorage value under codex.chatgpt-conversations.device-id (via the did-runtime trigger); this installation: a05f9cdd-ca51-4a91-9da1-9c374dfe0536.
  • Device registration: the one already made by the app — the cookies _devicecheck (.chatgpt.com) and __oailb (.chatgpt.com and .chat.openai.com) ride along with the trigger's same-origin electron.net fetch automatically. Re-registering (POST /devicecheck) per run is an anomaly that caused 403/variance; do not.
  • A1 validated results: challenge 200, prepare 200 (conduit), /f/conversation 200 (SSE 10–21KB), model tool call → client return 200 → model continues; multi-turn continuation in the same conversation 200 ("De nada.").

FLOW B — Sentinel / PoW (fallback path, NOT YET TESTED)

When DeviceCheck is unavailable (non-Apple platforms or the platform-gate flip), the app uses the sentinel path: POST /sentinel/chat-requirements/prepare (fingerprint + PoW; desktop FNV-1a murmur-finalized family; originator: Codex Browser, Chrome-like UA with sec-ch-ua), the sentinel heartbeat, and the Windows sandbox onboarding (see sentinel-fallback-validation and proof-of-work). It was exercised for observation only (fingerprint values, heartbeat, Windows onboarding UI) — generation was never run; that is the definition of flow B for the next phase.

Cross-references