bug: Codex CLI Thinking Signature

[blrcoderbro]

Affected area

Provider integration

What broke?

■ {"error":{"message":"The encrypted content VPy0...8OA= could not be verified. Reason: Encrypted content could not be
decrypted or parsed.","type":"invalid_request_error","code":"thinking_signature_invalid"}}

Reproduction steps

No response

Expected behavior

No response

Actual behavior

No response

CCS version

No response

Operating system

None

Environment details

No response

Logs, screenshots, or terminal output

Before submitting

• I searched existing issues first.
• I removed secrets and private data from logs/screenshots.
• I can still reproduce this on the latest released or dev build.

[kaitranntt]

I could not safely turn this into a code change from the current report yet, so leaving it open as needs-repro. The most likely areas are Codex route/profile selection or CLIProxy request translation, but we need one concrete failing request to avoid patching the wrong layer.

Please add:

• ccs --version
• Exact invocation/profile used
• Whether it happens on the first turn or only on follow-up turns
• ccs doctor output, especially any stale /api/provider/codex or Codex translator settings
• A redacted request or CLIProxy log showing route, model, and response body when the thinking-signature error appears

With that, I can reproduce against the exact provider path and make a targeted fix.

[blrcoderbro]

I'm using the latest dev version of CCS.

I'm using the Codex CLI, latest version.

This error is a little bit occasional.

Last I saw it was yesterday, and before that I saw it 2-3 days ago.

This error is coming with GPT-5.4 generally.

[kaitranntt]

Thanks. Please confirm this on ccs --version 8.1.4-dev.1 or newer; several Codex request-path fixes landed today.

Because the error is occasional and GPT-5.4-specific, I still need one captured failing request path before changing code. Most likely areas are Codex reasoning/tuning injection or upstream Codex rejecting encrypted reasoning content on a follow-up turn, but a blind patch could make GPT-5.4 routing worse.

Useful next repro data:

• Exact command/profile used and whether it is first turn or follow-up turn
• Whether it disappears with CCS_THINKING=off for the same workflow
• Whether it disappears with a lower explicit effort, e.g. --effort low
• Redacted ~/.ccs/codex-reasoning-proxy.log lines around the failure after running with CCS_CODEX_REASONING_TRACE=1
• Redacted CLIProxy log/request metadata showing route, model, and status/body for the failed request; no prompt text or tokens

Once one failing path is pinned, I can turn it into a targeted test and fix.

[blrcoderbro]

=== REQUEST INFO ===
Version: 7.1.15-1-plus
URL: /api/provider/codex/responses
Method: POST
Downstream Transport: http
Upstream Transport: http
Timestamp: 2026-05-30T00:24:56.0802307+05:30

=== HEADERS ===
Thread-Id: 019e7515-8ec5-7952-9d68-532effc264da
Authorization: Bearer ccs-...aged
Content-Type: application/json
Accept: text/event-stream
Session-Id: 019e7515-8ec5-7952-9d68-532effc264da
Content-Length: 243118
X-Codex-Beta-Features: terminal_resize_reflow
X-Client-Request-Id: 019e7515-8ec5-7952-9d68-532effc264da
Originator: codex-tui
User-Agent: codex-tui/0.134.0 (Windows 10.0.19045; x86_64) unknown (codex-tui; 0.134.0)
X-Codex-Turn-Metadata: {"session_id":"019e7515-8ec5-9d68","thread_id":"019e7515-8ec5-7952-9d68-532effc264da","thread_source":"user","turn_id":"-ad85-7072-9fae-e3b4f2b21284","workspaces":

=== REQUEST BODY ===
{"model":"gpt-5.4-mini"}

=== API RESPONSE ===
Timestamp: 2026-05-30T00:24:56.7843143+05:30
{"error":{"message":"The encrypted content Ee8T...Tf8= could not be verified. Reason: Encrypted content could not be decrypted or parsed.","type":"invalid_request_error","code":"thinking_signature_invalid"}}

=== RESPONSE ===
Status: 400
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: *
Content-Type: application/json
Content-Length: 207

{"error":{"message":"The encrypted content Ee8T...Tf8= could not be verified. Reason: Encrypted content could not be decrypted or parsed.","type":"invalid_request_error","code":"thinking_signature_invalid"}}

[blrcoderbro]

i am on latest dev release

[kaitranntt]

Diagnostic findings (read-only investigation of CLIProxyAPIPlus + upstream CLIProxyAPI source). No code change recommended yet — this needs a routing/architecture decision.

Observed symptom

Occasional 400 {"code":"thinking_signature_invalid","message":"The encrypted content ... could not be verified. Reason: Encrypted content could not be decrypted or parsed."} on POST /api/provider/codex/responses, model gpt-5.4-mini, v7.1.15-1-plus. Bodies are large (~243KB) because they carry prior-turn reasoning items.

Suspected root cause

The proxy does not generate this error — it renames an upstream OpenAI decrypt failure. The encrypted reasoning content replayed from a prior turn was encrypted under a different account key than the account selected for the current turn:

1. Default selector is plain round-robin, not session-sticky. sdk/cliproxy/builder.go:228-230 wires the default RoundRobinSelector. SessionAffinity is an opt-in flag, default false (internal/config/config.go:278). With many Codex OAuth accounts in the pool, each turn can land on a different account.
2. Codex reasoning.encrypted_content is bound to the per-account encryption key. Replaying a prior turn's encrypted_content to a different account yields upstream "Encrypted content could not be decrypted or parsed", which internal/runtime/executor/codex_executor.go:1003-1004 reclassifies to code thinking_signature_invalid.
3. The existing guard is shape-only. sanitizeOpenAIResponsesReasoningEncryptedContent (internal/runtime/executor/openai_responses_signature.go) calls InspectGPTReasoningSignature (gpt_validation.go:24), which the code itself documents as a TRANSPORT-SHAPE check that "does not prove decryptability". Well-formed cross-account content passes the guard and still reaches upstream.
4. Even enabling session-affinity is currently unreliable for Codex. extractSessionIDs (sdk/cliproxy/auth/selector.go:619) matches header Session_id (underscore), but Codex CLI sends Session-Id (hyphen) + Thread-Id. It falls through to X-Client-Request-Id (selector.go:633), which is per-request, not per-session — so binding would not stay stable across turns.

Amplifier: codex_executor.go unconditionally deletes previous_response_id (lines 280, 542, 676), forcing a full stateless replay of all prior reasoning items every turn. That re-sends old encrypted_content on each request rather than relying on upstream state, so any cross-account drift fails more often. The deletion is likely intentional (accounts do not share response-id state), so not a fix target by itself.

Why a blind fix is risky

Three candidate fixes, each with real regression risk:

• (a) Make session-affinity default-on for codex AND fix header extraction to read Session-Id/Thread-Id so codex turns pin to one account.
• (b) Strip ALL prior-turn reasoning encrypted_content whenever the selected account differs from the producing account (requires tracking the producing account, not currently stored).
• (c) Make round-robin account-sticky per conversation.

Any of these can regress the working single-account path or break codex routing. A prior codex-area fix already failed once (#1406), so this should not be patched speculatively.

Recommended next step / info needed

To confirm the in-the-wild trigger we need from a repro:

• Current session-affinity config value (on/off).
• Selector logs across a failing multi-turn codex session showing whether consecutive turns hit different accounts.
• The exact session-identifying headers the user's Codex client emits (Session-Id/Thread-Id/X-Codex-Turn-Metadata).

As a quick diagnostic the maintainer already suggested: CCS_THINKING=off / --effort low reduces/removes reasoning replay and should make the error disappear if this root cause is correct. Confirming that, plus the selector logs above, would let us pick between fixes (a)/(b)/(c) with confidence.