Artifacts tool fails because pinned artifact-runtime-v2.5.6 manifest is missing from public GitHub releases

Open 💬 0 comments Opened Mar 21, 2026 by MaxFabian25

What version of Codex CLI is running?

codex-cli 0.117.0-alpha.6

What subscription do you have?

API key auth (auth_mode from ~/.codex/auth.json); subscription tier is not material to this repro.

Which model were you using?

N/A for the core failure. The blocker is the public runtime fetch path before a successful artifacts run can complete.

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

WSL2 Ubuntu via bash in a terminal session.

What issue are you seeing?

The public artifacts runtime release pinned by the CLI is missing from GitHub releases.

The current runtime manager expects artifact-runtime-v2.5.6, but the public release tag/manifest is not available:

  • Tag lookup: https://api.github.com/repos/openai/codex/releases/tags/artifact-runtime-v2.5.6 returns 404
  • Manifest URL: https://github.com/openai/codex/releases/download/artifact-runtime-v2.5.6/artifact-runtime-v2.5.6-manifest.json

Exact verifier failure from the current source tree:

artifact runtime verification failed: failed to fetch manifest https://github.com/openai/codex/releases/download/artifact-runtime-v2.5.6/artifact-runtime-v2.5.6-manifest.json: HTTP 404

So the CLI is pinned to a runtime version that is not publicly downloadable from the expected release path.

What steps can reproduce the bug?

  1. Install a released Codex CLI that is pinned to artifact-runtime-v2.5.6.
  2. Enable the artifact feature.
  3. Use a fresh CODEX_HOME with no preinstalled artifact runtime and no CODEX_ARTIFACT_RUNTIME_ROOT override.
  4. Trigger an artifacts invocation, or inspect the expected runtime manifest URL directly.
  5. The CLI/runtime path expects:

https://github.com/openai/codex/releases/download/artifact-runtime-v2.5.6/artifact-runtime-v2.5.6-manifest.json

  1. That URL currently returns 404, so managed runtime installation cannot succeed from public GitHub assets.

For isolation, I also verified the positive path locally by staging a 2.5.6 runtime package behind a local HTTP release root and running a clean-host managed-install smoke. That successfully installed into:

/tmp/artifact-runtime-clean-host-smoke-main/codex-home/packages/artifacts/2.5.6/linux-x64

and exported a valid .pptx at:

/tmp/artifact-runtime-clean-host-smoke-main/artifacts-clean-host-smoke.pptx

That suggests the main blocker is public runtime publication/availability, not the basic managed-install flow.

What is the expected behavior?

One of these should be true:

  • artifact-runtime-v2.5.6 is published publicly with the expected manifest and per-platform archives, and artifacts managed install succeeds on a clean host.
  • Or the CLI should not expose/advertise the artifacts tool when the pinned public runtime release is unavailable.

Additional information

I have a ready patch on my fork if maintainers want to invite a PR after triage:

  • Branch: MaxFabian25:maxfa/artifacts-runtime-release-proof
  • Commit: 2ef2d4510f4e2eee242a4770120fd3ddeedadc93

That patch includes:

  • a release verifier for the pinned artifact runtime
  • runtime release asset staging/publish workflow pieces
  • a clean-host smoke runner for managed install + PPTX export
  • minimal artifacts runtime compatibility/fallback work used for validation

I am not opening a PR proactively because docs/contributing.md says external code contributions are invitation-only.

View original on GitHub ↗