Amazon Bedrock: model switch compacts with the previous model when comp_hash differs; the new model can't read the compaction item and the turn hangs until SSE idle timeout #48949

What version of Codex CLI is running?

0.158.0 (also 0.157.1, 0.158.0-alpha.2 / alpha.2.1 / alpha.15.4, 0.159.0-alpha.1 / alpha.12; Desktop 26.924.20706 and 26.924.22138)

What subscription do you have?

None. Amazon Bedrock provider with AWS credentials

Which model were you using?

openai.gpt-5.5 / openai.gpt-5.4 -> openai.gpt-6-luna / openai.gpt-6-sol (Amazon Bedrock, us-east-1)

What platform is your computer?

macOS 26 (Darwin 25.6.0), arm64

What issue are you seeing?

On the amazon-bedrock provider, switching models mid-thread between models with different comp_hash values makes the next turn hang with no error. For example, openai.gpt-5.5 → openai.gpt-6-luna.

Codex runs a pre-turn compaction with the previous model (CompactionReason::CompHashChanged). It then sends that model's compaction item to the new model. Bedrock accepts the request with HTTP 200 and emits response.created and response.in_progress. After that it sends only SSE keepalive comments. Codex waits for the stream idle timeout and prints Reconnecting... n/5 (stream disconnected before completion: idle timeout waiting for SSE). After the retries it fails with Connection failed: error sending request. A user saw about 21–25 minutes pass before the error, with last_agent_message: null.

A new thread on the target model works. So does any switch that doesn't compact.

Root cause (source at rust-v0.158.0, 064c6b8c)

codex-rs/core/src/session/turn.rs, maybe_run_previous_model_inline_compact (lines 1339–1384):

let should_compact_for_comp_hash_change = comp_hash_changed(
    previous_turn_settings.comp_hash.as_deref(),
    turn_context.model_info().comp_hash.as_deref(),
);
// ...
if should_compact_for_comp_hash_change {
    let step_context = sess
        .capture_step_context(Arc::clone(&previous_model_turn_context), cancellation_token) // previous model
        .await?;
    // ...
    run_auto_compact(sess, step_context, fallback_step_context, client_session,
        InitialContextInjection::DoNotInject, CompactionReason::CompHashChanged, CompactionPhase::PreTurn).await?;

comp_hash_changed (line 1304) returns true only when both hashes are present and differ. The current-model fallback (capture_current_model_fallback_step_context, lines 1314–1333) returns None unless the session uses the Codex backend with an OpenAI provider, so Bedrock never gets it.

The Bedrock model list (codex-rs/model-provider/src/amazon_bedrock/catalog.rs) copies comp_hash from codex-rs/models-manager/models.json:

So any switch between 2911 and 3000 compacts with the old model. The resulting item is then unreadable by the new model on Bedrock (see the direct replay below). In 0.158.0, 5.4 ↔ 6-* stopped failing only because gpt-5.4 lost its hash when it was removed from the list. 5.5 ↔ 6-* still fails.

What steps can reproduce the bug?

Minimal config.toml (a separate CODEX_HOME with nothing else in it):

model_provider = "amazon-bedrock"
model = "openai.gpt-5.5"

[model_providers.amazon-bedrock.aws]
region = "us-east-1"

codex exec --skip-git-repo-check --json "hi"          # note thread_id
codex exec --skip-git-repo-check --json -m openai.gpt-6-luna resume <thread_id> "ok"

The second command logs a compacted record in the rollout, then prints Reconnecting... 1/5 (stream disconnected before completion: idle timeout waiting for SSE) and never completes.

Version × switch matrix. Each switch ran a turn on the first model and then resumed with -m <second model>. ✅ means completed in under 20 s; ❌ means compacted and then no reply within 150 s.

Every ❌ had a compacted record right before the stalled turn, and every switch that didn't compact passed. Desktop 26.924.20706 bundles 0.158.0-alpha.2 and 26.924.22138 bundles 0.158.0-alpha.2.1; both reproduce. Desktop 26.917.71314 bundles 0.155.0-alpha.16.4 and doesn't.

Direct replay against Bedrock. Signed POST https://bedrock-mantle.us-east-1.api.aws/openai/v1/responses with stream: true, store: false, and input = [user "hi", <compaction item from the rollout>, user "ok"]:

❌ here means response.created and response.in_progress, then only keepalive comments for 90 s with no output. The same request without the compaction item passes in about 1.5 s. A full Codex-shaped request (instructions, tools, reasoning, text.verbosity) without a compaction item also passes on gpt-6-luna.

What is the expected behavior?

Switching models on Bedrock should continue the conversation. If compaction data can't be carried across comp_hash values, Codex shouldn't send an item the new model can't read. The turn should also fail fast instead of hanging until the idle timeout.

Additional information

Possible fixes, any of which avoids the hang:

1. When comp_hash differs, run the compaction with the new model, or give Bedrock a current-model fallback like the Codex-backend path has.
2. When comp_hash differs on a provider without that fallback, drop the old model's compaction item and carry over a plain-text summary.
3. If the Bedrock blobs really are compatible across these models, set matching comp_hash values in the Bedrock list.

On the server side, Bedrock keeps the stream open instead of returning an error such as invalid_encrypted_content (see #25290). That turns a clear failure into a 5-minute idle timeout per attempt. Faster handling of this on the client side is also discussed in #43140.

Related: #46474 (Bedrock model switch replays incompatible encrypted reasoning), #32453 (model switch blocked when previous-model compaction fails), #43140 (stream failures surface as idle timeout waiting for SSE).

Workarounds for affected users: start a new thread instead of switching between 2911 and 3000 models, or use a Desktop build that bundles ≤ 0.155 (for example, 26.917.71314).