Amazon Bedrock turn fails with generic "Internal server error" while a successful exec result remains recoverable

What version of Codex CLI is running?

codex-cli 0.145.0

What subscription do you have?

Amazon Bedrock

Which model were you using?

openai.gpt-5.6-sol, high reasoning effort

What platform is your computer?

Linux 6.12.95+deb13-cloud-amd64 x86_64, Debian 13

What terminal emulator and version are you using?

SSH terminal with zsh

Codex doctor report

Relevant redacted fields:

{
  "codexVersion": "0.145.0",
  "model": "openai.gpt-5.6-sol",
  "modelProvider": "amazon-bedrock",
  "wireApi": "responses",
  "supportsWebsockets": false
}

Provider configuration, installation, state databases, and rollout parity passed. The report's overall failure was only for TERM=dumb, which appears unrelated.

What issue are you seeing?

An Amazon Bedrock model turn failed with only:

Internal server error

The rollout recorded codex_error_info: "other" and no provider error code, request ID, or actionable diagnostics.

Immediately before the failure, the agent started an exec command. The initial tool result said the process was running and returned a session ID. The turn then failed before the agent polled that session again.

After resuming the thread, polling the same exec session returned a successful test result. The successful result had remained unread but recoverable across the failed model turn.

Redacted timeline:

14:02:41 exec_command: bun test ...
14:02:42 Process running with session ID 61941
14:02:45 task_complete:
           error.message = "Internal server error"
           error.codex_error_info = "other"

After resuming:
write_stdin(session_id=61941)
Process exited with code 0
1 pass, 0 fail

The generic error led the resumed agent to incorrectly explain the incident as a test-infrastructure failure, even though the failed component was the model/provider turn.

What steps can reproduce the bug?

This has been observed once and is not currently deterministic:

1. Configure Codex CLI with the built-in amazon-bedrock provider.
2. Use openai.gpt-5.6-sol.
3. Run a long agent turn that starts an exec command with a short yield timeout.
4. If the provider turn terminates with an internal error before the exec session is polled again, resume the thread.
5. Poll the previous session ID and observe that its successful result remains available despite the failed turn.

Thread ID: 019fa3ca-79fe-7661-8cb3-0a8f74a6bd24

What is the expected behavior?

When a model turn fails after starting an asynchronous exec session, Codex should:

1. Clearly distinguish the provider/model failure from the tool command result.
2. Preserve and display any outstanding or unread exec session IDs.
3. Reconcile those sessions when the thread resumes, before reasoning about the cause of the failure.
4. Preserve bounded provider diagnostics such as the error code and request ID instead of reporting only codex_error_info: "other".

Additional information

The local logs do not contain the raw provider HTTP or SSE event for this turn, so this report does not claim that the provider returned HTTP 500 or the same response.failed event described in #27185.

Related issues:

• #27292: same generic visible error, without Bedrock/tool-lifecycle evidence
• #32871: provider error details discarded for HTTP 500 responses
• #27185: closed Bedrock issue involving response.failed after completed output