Feature proposal: emit a machine-readable Codex run manifest

Proposal

Add an optional machine-readable run manifest for each Codex Action invocation so CI systems can consume execution metadata without parsing console logs or model-generated text.

For example, an input/output pair such as:

with:
  run-manifest-file: codex-run.json

could cause the Action runtime to write a versioned JSON document and expose its path as an Action output.

A narrow first version could include only deterministic, non-sensitive metadata available to the Action itself:

• manifest schema version;
• Codex Action version and Codex CLI version;
• selected model and reasoning effort;
• permission profile / safety strategy;
• repository and pinned Git SHA;
• working-directory path relative to the workspace;
• prompt source type plus a hash of the prompt, not prompt contents;
• output-schema hash when present;
• process exit status and start/end/duration;
• changed paths and diffstat after the run;
• hashes of final-message / output-file artifacts when present;
• usage summary when the CLI exposes it in a stable machine-readable form.

The manifest should explicitly avoid raw prompts, tool arguments/output, environment variables, API keys, tokens, or secrets.

Why this is useful

The Action currently exposes the final message, but CI consumers often need to answer operational questions such as:

• Which Codex/action version and configuration produced this patch?
• Which repository state did it start from?
• What files changed?
• Did the Codex process finish successfully?
• Can this run be compared with a later run without scraping human-oriented logs?

A small first-party manifest would improve auditability, provenance, reproducibility, and downstream automation while keeping the model's natural-language answer separate from execution metadata.

Behaviour

The manifest should be generated by the Action/runtime, not by prompting the model to describe its own run. Where possible, it should also be written on known failure paths so CI systems have a structured diagnostic record even when the Codex step does not succeed.

This does not need to become a full telemetry or tracing system. The initial contract could be intentionally small and versioned so fields can be added safely later.

I searched current issues for run manifests, machine-readable run metadata, provenance artifacts, and action-output metadata and did not find an equivalent proposal.

No implementation files or tests are named. Start by locating the Action runtime and its existing inputs and outputs, then define the smallest versioned JSON manifest contract. Done means an optional manifest path and Action output work on success and known failures while excluding prompts, tool data, environment variables, and secrets.