macOS PDF workflow uses PATH Python instead of bundled runtime

Summary

On macOS local Codex runs, the bundled PDF libraries are present in Codex's primary runtime, but a PDF workflow that invokes bare python3 resolves to the user's PATH Python instead. This causes PDF generation to fail with ModuleNotFoundError even though the bundled runtime can import the required libraries.

Environment

• Codex CLI: 0.146.1
• macOS: 26.6
• PATH Python: 3.14.5
• Codex bundled Python: 3.12.13

Minimal reproduction

python3 -c 'import reportlab'

Actual result:

ModuleNotFoundError: No module named 'reportlab'

The bundled Codex runtime succeeds with the same libraries:

<Codex primary runtime>/dependencies/python/bin/python3 -c \
  'import reportlab, pdfplumber, pypdf; print("imports succeed")'

Actual result:

imports succeed

Impact

Agents asked to create PDFs can stall, report that the tooling is unavailable, or attempt unnecessary package installation. The behavior reproduces across new local sessions and unrelated repositories because they share the same local runtime and shell PATH.

Expected behavior

PDF workflows should reliably use the bundled Python runtime that contains reportlab, pdfplumber, and pypdf, or Codex should expose a stable documented command/environment variable for that runtime.

Suggested fix

Either:

1. Have the bundled PDF skill invoke the bundled interpreter explicitly; or
2. Expose a stable, task-scoped PDF Python command/environment variable.

Please avoid requiring users to globally change PATH, since that can interfere with project-specific Python environments.