Expose cache/session affinity for `codex exec --ephemeral` without native transcript replay

What variant of Codex are you using?

CLI (codex exec --json --ephemeral)

What feature would you like to see?

TLDR Requested behavior:

For codex exec --json --ephemeral and app-server one-shot integrations,
please expose a supported prompt_cache_key / cache_affinity_id option
that is used for the primary Responses request body instead of the generated
Codex thread id.

This should not imply native transcript resume, native history persistence,
or model-visible replay of prior Codex turns. The goal is only cache routing
affinity for externally managed transcripts.

Summary

I am integrating Codex CLI into a local AI workspace that owns its own chat transcript, tool history, file references, and prompt-compression system. For normal turns, the app launches fresh one-shot Codex runs:

codex exec --json --ephemeral ...

The app intentionally does not use Codex native resume for normal chat continuity, because Codex resume appears to replay/store Codex-owned native history. That conflicts with apps that already own the transcript and need to control exactly what history/tool output is sent.

The problem is that prompt caching across these fresh one-shot runs appears to stay pinned to a small native prefix, even when the stable app/system prefix is identical.

Environment

• Codex CLI: codex-cli 0.130.0
• Auth path: ChatGPT/Codex subscription auth
• Normal run shape: fresh codex exec --json --ephemeral per user turn
• Managed config includes history.persistence = "none"

Observed Behavior

Fresh one-shot runs often report cached input pinned around values like:

• 2,432
• 3,456
• 5,504
• 6,528

Tool-call bursts inside one Codex run cache better, and codex exec resume improves cached input, which suggests prompt caching works when Codex keeps native session/thread continuity.

But resume also appears to carry Codex native transcript/session state, which duplicates the app-owned history and can cause context/input growth.

What We Tried

We tried many prompt-stability and config changes, including:

• Removing/blanking project .codex, AGENTS.md, and .agents during tests.
• Moving custom Codex config out of the managed Codex home.
• Disabling Codex Apps.
• Suppressing Codex-native skill injection.
• Disabling optional app tools/MCPs/subagents.
• Passing a stable app-level prompt_cache_key.
• Splitting stable instructions into developer_instructions.
• Running from tiny test projects instead of the real repo.
• Dropping --ephemeral while keeping history.persistence = "none".
• Testing history.max_bytes.
• Testing codex exec resume.
• Testing codex app-server thread reuse plus thread/rollback.
• Testing a local proxy proof to inspect the actual Responses request body.

Key Findings

The proxy proof showed that Codex's actual /v1/responses request includes prompt_cache_key, but the value was the fresh Codex thread id. The app-provided stable --config prompt_cache_key=... did not appear to override that internal Responses request key.

App-server same-thread rollback improved cached input, but provider input still grew rapidly across turns. Restart/resume after rollback still grew input and weakened cache.

A local custom-provider proxy could mechanically rewrite the request body, but forwarding ChatGPT/Codex subscription auth did not work through the public API path, and a simple proxy to the ChatGPT backend was not viable. API-key proxying is not a good product answer for users relying on Codex subscription access.

Desired Capability

It would be very helpful if Codex exposed a supported way to reuse prompt-cache/session affinity across independent one-shot runs without requiring Codex to replay or own the transcript.

Possible shapes:

• A documented config/CLI/app-server field that actually overrides the internal Responses prompt_cache_key.
• A stable cache_session_id / cache_affinity_id for codex exec.
• A resume mode that reuses cache identity but does not replay/persist native transcript history.
• A way to combine history.persistence = "none" with a stable cache namespace.
• App-server support for stable cache affinity without model-visible thread history growth.

Why This Matters

Apps integrating Codex CLI may already own transcript storage, compression, tool rendering, and context trimming. In those architectures, using Codex native resume/history creates duplicated state and fast context growth.

The ideal behavior is:

• App owns the transcript.
• Codex runs one-shot turns.
• Stable repeated prefixes get normal prompt-cache benefit.
• Codex does not need to store/replay a second copy of the conversation.

Is there currently a supported way to do this? If not, could Codex expose one?

Additional information

This is for a third-party/local app integration that uses Codex CLI as a managed subprocess. The main constraint is that users should be able to use their normal ChatGPT/Codex subscription auth, not only Platform API-key billing.