fix(codex): bound prompt cache keys

[JackALaing]

Summary

• Keep OpenAI Responses prompt_cache_key values within the provider's 64-character limit.
• Preserve existing short session IDs unchanged for prompt-cache continuity.
• Use a stable hash suffix for longer session IDs, including cron session IDs derived from long job names.

Test Plan

• python -m pytest tests/agent/transports/test_codex_transport.py -q
• python -m py_compile agent/transports/codex.py
• git diff --check

Platforms Tested

• macOS arm64, Python 3.13.13.

Related / competing PRs

• PR #10006 improves Codex prompt-cache routing headers and usage accounting, but does not touch agent/transports/codex.py or bound the OpenAI prompt_cache_key body field.
• PR #5252 proposes broader provider-aware session-affinity routing. This PR is a smaller bug fix for the current Responses transport and can stand independently.
• PR #6461 was a closed SSE proxy cache-routing attempt; it does not supersede this OpenAI request validation fix.
• Searched PRs/issues for prompt_cache_key length, prompt_cache_key Responses, and prompt_cache_key; found no open or merged PR specifically fixing the 64-character limit failure.

Notes/Risks

• Long cache keys remain deterministic, so repeated calls for the same Hermes session still share the same prompt-cache identity.
• Short cache keys are unchanged to avoid unnecessary cache churn.
• Cross-platform impact is low: this only changes request kwargs construction for the Responses API transport and adds no file I/O, shell commands, process management, or platform-specific behavior.

[alt-glitch]

Likely duplicate of #24273 — both fix Codex transport prompt_cache_key exceeding OpenAI's 64-character limit by hashing oversized session IDs. Same bug (400 errors on long cron session IDs), same fix approach.

[JackALaing]

The main difference here is that this PR preserves a readable prefix and appends a short hash, rather than replacing the entire value with a full SHA256 digest. That keeps the key within OpenAI’s 64-char limit while preserving some operator/debug value in logs and traces. For example, a long cron/session ID still shows the job/session family prefix, with the hash suffix preventing collisions.

I’m fine closing this in favor of #24273 if maintainers prefer the older PR.

[teknium1]

Thanks for the focused cache-key fix. This is an automated hermes-sweeper review: current main already provides the reported bounded-key behavior through a stronger content-addressed approach.

• agent/transports/codex.py:131-138 always supplies non-empty instructions, falling back to DEFAULT_AGENT_IDENTITY.
• agent/transports/codex.py:16-46 derives a fixed pck_ + 24-character SHA-256 prefix key (28 characters total), and agent/transports/codex.py:252-263 uses it instead of the raw session ID.
• tests/agent/transports/test_codex_transport.py:86-113 covers cron-shaped session IDs and verifies timestamp-distinct fires retain one stable cache key.
• This landed in 7a65800fed6f7b3f87c264018b7456b250e150ac / PR fix(cache): content-address prompt_cache_key so recurring cron jobs reuse the warm prefix #52295, including the same Codex transport surface discussed in the duplicate cluster (fix(codex): bound prompt cache key length #24273, fix(cron): cap session_id at 64 chars to satisfy prompt_cache_key limit #28307, fix: clamp codex prompt_cache_key to 64 chars #51037, and fix(codex): clamp prompt_cache_key to 64 chars for Codex/ChatGPT backend #62266).

The current implementation both stays within the provider limit and avoids cache-cold recurring cron runs.