[codex] request desktop attestation from app

[jiamingz42]

Summary

TL;DR: teaches codex-rs / app-server to request a desktop-provided attestation token and attach it as x-oai-attestation on the scoped ChatGPT Codex request paths.

Details

This PR teaches the Codex app-server runtime how to request and attach an attestation token. It does not generate DeviceCheck tokens directly; instead, it relies on the connected desktop app to advertise that it can generate attestation and then asks that app for a fresh header value when needed.

The flow is:

1. The Codex desktop app connects to app-server.
2. During initialize, the app can advertise that it supports requestAttestation.
3. Before app-server calls selected ChatGPT Codex endpoints, it sends the internal server request attestation/generate to the app.
4. app-server receives a pre-encoded header value back.
5. app-server forwards that value as x-oai-attestation on the scoped outbound requests.

The code in this repo is mostly protocol and runtime plumbing: it adds the app-server request/response shape, introduces an attestation provider in core, wires that provider into Responses / compaction / realtime setup paths, and covers the intended scoping with tests. The signed macOS DeviceCheck generation remains owned by the desktop app PR.

Related PR

• Codex desktop app implementation: https://github.com/openai/openai/pull/878649

Validation

Tests run

cargo test -p codex-app-server-protocol
cargo test -p codex-core attestation --lib
cargo test -p codex-app-server --lib attestation

Also ran:

just fix -p codex-core
just fix -p codex-app-server
just fix -p codex-app-server-protocol
just fmt
just write-app-server-schema

E2E DeviceCheck validation

First validated the signed desktop app boundary directly: launched a packaged signed Codex.app, sent attestation/generate, decoded the returned v1. attestation header, and validated the extracted DeviceCheck token with personal/jm/verify_devicecheck_token.py using bundle ID com.openai.codex. Apple returned status_code: 200 and is_ok: true.

Then ran the fuller app + app-server flow. The packaged Codex.app launched a current-branch app-server via CODEX_CLI_PATH, and a local MITM proxy intercepted outbound chatgpt.com traffic. The app-server requested attestation/generate from the real Electron app process, and the intercepted /backend-api/codex/responses traffic included x-oai-attestation on both routes:

GET  /backend-api/codex/responses  Upgrade: websocket  x-oai-attestation: present
POST /backend-api/codex/responses  Upgrade: none       x-oai-attestation: present

The captured header decoded to a DeviceCheck token that also validated with Apple for com.openai.codex (status_code: 200, is_ok: true, team 2DC432GLL2).

[jiamingz42]

Addressed in 3cbcba1: websocket handshake headers now go through the same scoped AttestationPurpose::Response path as HTTP /responses, and I added a regression test covering x-oai-attestation on the websocket handshake. (Reply by Codex)

[jiamingz42]

Just did a rebase and resolved some conflicts. Need to double check it does not break anything. (Reply by Codex)

[pakrym-oai]

Let's try and drop uses_chatgpt_auth from ApiProvider. ApiProvider is an abstraction that should know about details of the provider implementation.

[jiamingz42]

🙏 @euroelessar @pakrym-oai it's green now. taking a last pass and then merging it.