Codex thread resume fails when completed subagent activity is decoded

[BraydenPB]

What happened

An existing Codex thread became unusable in T3 Code after a successful turn that used several subagents.

Opening the thread or sending another message failed immediately while T3 attempted to resume the provider thread:

ProviderAdapterProcessError: Provider adapter process error (codex):
Invalid payload for method 'thread/resume' during 'decode-payload'

SchemaError: Expected "started" | "interacted" | "interrupted"
at ["thread"]["turns"][1]["items"][16]["kind"]

The original turn completed successfully. The failure appeared when T3 tried to resume the thread afterward.

Diagnosis

Codex CLI 0.150.0 returns persisted SubAgentActivity items with:

{
  "type": "SubAgentActivity",
  "kind": "completed"
}

T3's generated decoder for V2ThreadResumeResponse currently accepts only:

"started" | "interacted" | "interrupted"

It does not accept "completed". Current T3 main appears to retain the same three-value enum:

https://github.com/pingdotgg/t3code/blob/main/packages/effect-codex-app-server/src/_generated/schema.gen.ts#L8345-L8350

The generated files reference upstream Codex protocol commit 678157acaa819d5510adfe359abb5d0392cfe461. This appears to be protocol drift between the installed Codex CLI and T3's pinned/generated protocol schema.

Steps to reproduce

1. Use T3 Code with Codex CLI 0.150.0.
2. Start a Codex thread that launches one or more subagents.
3. Allow the subagents and parent turn to complete.
4. Close, switch away from, or otherwise cause T3 to resume the provider thread.
5. Reopen the thread or send another message.

The thread fails during thread/resume decoding when its history contains a completed SubAgentActivity.

Expected behavior

T3 should decode the resumed thread and allow the conversation to continue. Completed subagent activities should be restored as completed historical items.

Actual behavior

The provider response fails schema validation, making the entire thread unusable. Every subsequent turn fails before it starts.

Version

• T3 Code desktop: 0.0.34-nightly.20260825.1183
• T3 triage CLI context: 0.0.34
• Codex CLI: 0.150.0
• Model: gpt-5.6-sol

Environment

• Windows x64
• Windows version: 10.0.26200
• Node.js: v24.16.0
• T3 local server running on 127.0.0.1

Evidence

The affected Codex rollout contained five persisted event_msg / item_completed records whose nested item had type: "SubAgentActivity" and kind: "completed". The rollout contained 784 valid JSONL records.

After backing up the rollout, changing only those five nested values from "completed" to "interacted" allowed a direct thread/resume request to succeed. The response retained both original turns and the thread could be continued again.

This confirms that the unsupported SubAgentActivity.kind value, rather than general rollout corruption, caused the resume failure.

Related issues

No exact T3 duplicate was found. Potentially related, but not duplicates:

• [Bug]: Codex subagent progress floods orchestration ingestion and delays unrelated threads #5681 — subagent progress/orchestration ingestion rather than resume schema decoding.
• Resumed subagent loses completed status after app-server restart openai/codex#34220 — completed state being lost when resuming a subagent.
• Codex Desktop: completed subagents restore as Active after reload openai/codex#37042 — completed subagents being restored as active.

Suggested fix

Update the Codex protocol dependency and regenerate the Effect schemas so that SubAgentActivity.kind includes "completed".

Add a regression test that resumes a thread containing a completed subagent activity and verifies that:

1. thread/resume decodes successfully.
2. The completed state is preserved.
3. The parent thread remains usable.

It may also be worth making provider response decoding forward-compatible with newly added lifecycle enum values so one new status cannot make an entire historical thread unrecoverable.

Workaround

Starting a new thread avoids the affected history.

Editing the persisted rollout can recover an affected thread, but should only be done after creating a backup. In this case, replacing the five "completed" values with "interacted" restored the thread without losing either turn.

Filed by

Filed via T3 triage.

[t3dotgg]

Thanks for the detailed report. We believe this is fixed by PR #8346.

The PR adds completed to the SubAgentActivityKind schemas used by thread/resume. It also updates the generator and tests, so existing threads with completed subagent activity should now resume without editing their rollout history.

I'm closing this as fixed as part of an automated pass on all open issues. If this still happens in a build that includes PR #8346, please reply with the T3 Code version, Codex version, and the new decoder error, and we can reopen it.