Codex misalignmentPolicyViolation in thread history prevents resuming conversations

What happened

The T3 Code desktop app on a MacBook Pro, connected to a Linux T3 server, fails to continue an existing Codex conversation. The server reports ProviderAdapterProcessError while decoding thread/resume.

The user reported having to delete affected threads and clarified: "had to use new chats lost history this is bad". They could continue only by starting new chats, losing access to their previous conversation history and continuity. This is a disruption requiring abandonment of existing conversations, not merely an error banner. Permanent deletion of the underlying Codex history has not been established.

Diagnosis

Read-only inspection of the matching Codex thread history found that historical turn index 20 has status failed and this stored error:

{"message":"This request was blocked by our safety systems.","codexErrorInfo":"misalignmentPolicyViolation","additionalDetails":null,"misalignment":null}

The installed release's generated V2ThreadResumeResponse__CodexErrorInfo schema in packages/effect-codex-app-server/src/_generated/schema.gen.ts does not accept misalignmentPolicyViolation. The full resume response therefore fails validation before a new turn starts. The requested fix is to represent this historical provider error correctly while preserving its safety-blocked status.

The current main schema fetched during triage also lacks this value. Main was observed at 223ff4490f764a74ff911589e97b9bbcd595fee8; the schema was fetched through the main URL. No newer release was listed at investigation time.

Steps to reproduce

Inferred from the recorded failure; no new safety-blocked request was generated during triage:

1. Have a Codex conversation with a persisted failed turn whose codexErrorInfo is misalignmentPolicyViolation.
2. Attempt to continue it in T3, triggering thread/resume.
3. Observe decoding fail at that historical turn's error field.

A regression test can use a synthetic resume-response fixture containing that value.

Version

Server: 0.0.39-nightly.20260906.1293, commit d924fe266483e1d400775e3c3ce784f8e90f355f. Verified from the package used by the reported stack trace.

Environment

• Client: T3 desktop app on MacBook Pro; client version and macOS version not yet supplied.
• Server: Linux x64, kernel 7.0.0-31-generic, Node v22.23.2, active systemd user service.
• Codex CLI version not yet verified.

Evidence

CodexAppServerRequestError: Invalid payload for method 'thread/resume' during 'decode-payload'
SchemaError: Expected "contextWindowExceeded" | "sessionBudgetExceeded" |
"usageLimitExceeded" | "serverOverloaded" | "cyberPolicy" |
"internalServerError" | "unauthorized" | "badRequest" |
"threadRollbackFailed" | "sandboxError" | "rateLimitExceeded" | "other"
at ["thread"]["turns"][20]["error"]["codexErrorInfo"]

The matching persisted error is quoted above. No conversation content, credentials, or home directory paths are included.

Related issues

#8875 describes the same failure mechanism for rateLimitExceeded. This release already accepts that value; this report concerns the distinct unsupported misalignmentPolicyViolation value. Exact-value and broader resume/policy searches found no matching report.

Fix applied or workaround

The triage agent changed no application code, configuration, service state, or databases. The user resorted to new chats after deleting affected threads, losing access to the prior conversation history. Starting new chats allowed continued use but did not recover the affected conversations. There is no confirmed history-preserving recovery.

Follow-up read-only inspection also found recent, distinct session errors: Previous response owner account is unavailable; retry later (HTTP 502) and thread ... already has an active writer. Their relationship to the broader usability complaint is not yet established; they are not evidence that the schema mismatch explains every failure.

Filed by

Codex (GPT-6) via T3 triage.

Intended label: via-triage.