Codex misalignmentPolicyViolation in thread history prevents resuming conversations

[neronlux]

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.

[juliusmarminge]

Triage

Confirmed on current main (223ff4490f764a74ff911589e97b9bbcd595fee8). This is a real Codex resume decode bug, not a duplicate of #8875.

thread/resume is strictly decoded against the generated V2ThreadResumeResponse schema. A persisted failed turn with codexErrorInfo: "misalignmentPolicyViolation" is rejected before a new turn starts, and isRecoverableThreadResumeError does not treat decode-payload failures as recoverable. That matches the reported ProviderAdapterProcessError and the need to abandon the conversation.

The generated enum still accepts rateLimitExceeded (from #8897) but not misalignmentPolicyViolation:

• packages/effect-codex-app-server/src/_generated/schema.gen.ts (V2ThreadResumeResponse__CodexErrorInfo, also Read/Rollback)
• packages/effect-codex-app-server/scripts/generate.ts (applyCodex0151DefinitionCompatibility only appends rateLimitExceeded)
• Decode path: packages/effect-codex-app-server/src/client.ts, packages/effect-codex-app-server/src/_internal/shared.ts
• Resume fallback: apps/server/src/provider/Layers/CodexSessionRuntime.ts

T3's pinned Codex protocol ref (678157acaa819d5510adfe359abb5d0392cfe461) does not include this value. Current openai/codex main does — added in openai/codex#38682. Codex TUI also treats it as a terminal safety stop (openai/codex#39261). T3 should still accept the historical value so the thread can be opened and the blocked status preserved.

Suggested fix

Same pattern as #8897:

1. Add misalignmentPolicyViolation to the generator compatibility override for thread read/resume/rollback CodexErrorInfo (also consider fork + turn/completed notifications).
2. Regenerate the schema.
3. Add a synthetic fixture test like the existing rateLimitExceeded case in packages/effect-codex-app-server/src/schema.test.ts.
4. Keep the failed/safety-blocked status; do not map this value to other.

A full protocol refresh would also pick this up, but previous resume-drift work (#8346, closed #8342) preferred compatibility overrides to avoid breaking older Codex CLIs. A durable unknown-enum fallback would prevent the next new codexErrorInfo from bricking history again.

The later Previous response owner account is unavailable (HTTP 502) and thread ... already has an active writer errors are separate and are not explained by this schema gap.

Related: #8875 / #8897, #8355, #8322, #3742.

[realbakari]

Opened #10373 with the compatibility override from triage: misalignmentPolicyViolation is accepted on thread read/resume/rollback, plus fork and turn/completed. Decode keeps the variant instead of folding it into other.

Macroscope’s approvability check would have approved it; their correctness pass did not run because the workspace monthly spend cap was hit.