App Server: host-signed per-invocation task identity attestation

What variant of Codex are you using?

Codex Desktop on macOS with the bundled App Server.

• Desktop: 26.901.20858 (build 7658)
• Codex CLI/App Server: 0.153.0-alpha.5

What feature would you like to see?

Please expose a host-owned, independently verifiable attestation for the exact task/thread, turn, and invocation executing a request.

The current attestation/generate flow returns an opaque host token. In the shipped macOS handler, the visible wrapper binds device/app context (including the bundle and app session) but does not expose a verifiable task/thread/turn/invocation claim or a local verifier.

Minimum security properties

• Task, thread, turn, and invocation identities derived by the trusted host, never caller-selected.
• A verifier-generated nonce bound to one invocation.
• Issuer, audience, runtime/build, protocol/schema, issued-at, expiry, and single-use replay protection.
• Logical lineage kept distinct from execution incarnation/currentness.
• A correctly signed, unexpired attestation from a superseded invocation must fail current-authority verification after retry, replacement, or takeover.
• A documented signature/trust chain and verifier API with fail-closed behavior.
• Public schemas and positive, mismatch, stale, replay, supersession, and cross-thread substitution tests.
• Version-matched source provenance: repository, immutable commit, source paths, build-to-source mapping, applicable CODEOWNERS/approver, and the upstream verifier responsibility entry.

Static IDs, environment variables, working directories, model output, or caller-provided metadata are not sufficient evidence of the actual executor.

This is adjacent to #36489, but narrower: it requests per-invocation executor identity binding rather than only a launch-time capability/zero-history receipt.

Current verified gap

The public repository and some public ownership metadata are available, but they do not establish all of the following:

1. The version-controlled Desktop host source corresponding to the shipped Desktop build.
2. A reproducible Desktop build-to-source mapping with immutable commits and exact source paths.
3. An authenticated code owner or approver with effective review/merge authority for that source.
4. The version-matched App Server attestation source and protocol schema corresponding to the bundled runtime.
5. The upstream verifier source, trust anchors, verification policy, and named code/operational owner.
6. A supported private route through which an authorized repository administrator can provide signed provenance.

Public repository visibility, a public issue comment, a caller-selected identifier, or a self-authored statement cannot substitute for those items. The reporting account has public read access only and cannot manufacture repository, signing, verifier, adoption, or release authority.

Why the intake template is not attached publicly

A machine-readable intake template exists, but a blank template is not evidence and a filled template may contain non-public repository coordinates, exact source paths, permission records, approver identities, build/signing provenance, verifier responsibility data, and public-key trust material.

A public issue cannot:

• authenticate that the person completing the package has the claimed authority;
• provide a confidential channel for non-public provenance;
• prevent an unauthenticated party from filling the template with self-asserted data; or
• establish that a returned signature is bound to an approved organizational trust root.

Publishing the template here could also make an unfilled or self-filled document look like authority when it is not. For those reasons, the template will only be provided through a maintainer-approved private channel after the recipient's responsibility and delivery route are established.

No private key, secret, access token, password, reusable credential, or confidential source content is requested. Only verifiable provenance, public keys or fingerprints, immutable identifiers, scoped authority evidence, and digests should be returned.

Minimum contents of the private provenance package

An authorized maintainer or repository administrator would need to provide a signed package containing:

• Desktop host repository identifier, immutable commit, exact source paths, and SHA-256 digests.
• Reproducible mapping to Desktop 26.901.20858 build 7658, or to an explicitly approved successor build.
• Applicable CODEOWNERS or equivalent responsibility record, named approver, and authenticated review/merge permission evidence with scope and expiry.
• App Server repository/commit, exact attestation/generate and schema paths, digests, and test entry points matching Codex CLI/App Server 0.153.0-alpha.5.
• Upstream verifier repository/commit/source paths, issuer and audience rules, trust anchors, nonce/freshness/replay/supersession behavior, and named code and operational owners.
• Package signer identity, signing algorithm, public-key fingerprint or approved trust-chain reference, issued-at, expiry, package digest, and attachment digest manifest.

Every required item must be independently verifiable. Missing or unverifiable fields require fail-closed rejection.

Scope boundary

Receiving a valid provenance package would only establish a source-and-authority intake basis. It would not itself authorize implementation, compilation, testing, adoption, signing, release, deployment, or any downstream effect. Those actions would still require separate explicit authorization and validation.

Until a qualified attestation capability and its provenance are established, downstream systems that require proof of the actual executor must remain blocked rather than infer identity from caller-controlled or unsigned metadata.

Maintainer request

Please confirm whether a supported API or roadmap already exists. If the Desktop host or verifier sources are not public, please provide:

1. a secure/private channel suitable for the provenance package; and
2. an authorized maintainer, code owner, repository administrator, or verifier owner who can complete and sign it.

If an official existing document, API, or attestation verifier already satisfies these requirements, a link to the authoritative source and its version/build applicability would also be sufficient for evaluation.

No private task identifiers, local paths, file hashes, credentials, logs, project names, or product-specific details are included in this public issue.

Start by locating the public attestation/generate entry point and any matching protocol schema or test entry points for App Server 0.153.0-alpha.5. The issue does not name repository paths or establish source provenance for the bundled Desktop host. Done would require a version-matched, independently verifiable per-invocation attestation, verifier behavior, trust documentation, and the listed positive, mismatch, stale, replay, supersession, and cross-thread tests.