---
type: research
title: Flow Definitions — A / A0 / A1 / B (attestation vs PoW)
description: 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)
tags: [openai, flow, attestation, pow, sentinel, definitions, hierarchy]
timestamp: 2026-08-27
---

# Flow Definitions — A / A0 / A1 / B

Part of [openai-research](openai-research.md). 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](flow-a-403-cases.md)): 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](sentinel-fallback-validation.md) and [proof-of-work](proof-of-work.md)). **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

- [flow-a-manual-step-by-step](flow-a-manual-step-by-step.md) — the validated A1 sequence (executable by another agent)
- [flow-a-tool-protocol](flow-a-tool-protocol.md) — the validated local tool-calling protocol
- [flow-a-403-cases](flow-a-403-cases.md) — every 403 encountered and what each taught
- [attestation-flow](attestation-flow.md) — the DeviceCheck mechanism
- [proof-of-work](proof-of-work.md) — the sentinel/PoW mechanism (flow B)