[Bug]: Regression of #3742: Codex thread/resume rejects persisted subagent activity kind

[kevvykevwin]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Open an existing Codex-backed thread in T3 Code Alpha.
2. Restart T3 Code.
3. Reopen the same thread and send another message.
4. Retry after the first failure.

The affected thread is:
2d62072c-8127-4986-b3e6-d1f3b3b77608

Expected behavior

T3 Code resumes the persisted Codex thread and starts the next turn. If an older persisted item is incompatible, T3 Code should migrate it or provide a recovery path that preserves the conversation.

Actual behavior

Every attempt to continue this thread fails before the turn begins. Restarting T3 Code does not repair the thread. A newly created thread works, but the affected conversation cannot be continued. This appears to be a regression or narrower variant of #3742. That issue rejected the entire subAgentActivity item and was closed after PR #3036 regenerated the Codex schema. This failure reaches the nested kind field and rejects its persisted value.

Impact

Blocks work completely

Version or commit

T3 Code Alpha: 0.0.34 (bundle version 0.0.34)

Environment

macOS 26.5.1 (25F80) T3 Code Alpha 0.0.34 Codex CLI 0.150.0 Provider: Codex Runtime mode: full access

Logs or stack traces

ProviderAdapterProcessError: Provider adapter process error (codex) for thread 2d62072c-8127-4986-b3e6-d1f3b3b77608: Invalid payload for method 'thread/resume' during 'decode-payload'

Caused by:

SchemaError: Expected "started" | "interacted" | "interrupted"
  at ["thread"]["turns"][0]["items"][18]["kind"]

Three failed startSession attempts used the persisted resume cursor:

2026-08-26 15:32:05 MDT — trace 33495ffcf98222ea04b186ea3fef3fec
2026-08-26 15:32:28 MDT — trace ef3d3615247f735b116ab1abc0381775
2026-08-26 15:35:14 MDT — trace a30a45e45edd5fa509aa4475312551c6

provider.resume_cursor.source=persisted
provider.resume_cursor.present=true

Screenshots, recordings, or supporting files

Screenshot 2026-08-26 at 15.49.25.png
Screenshot 2026-08-26 at 15.49.33.png

Workaround

Create a new thread in the same project and manually provide a handoff summary. Restarting the application alone does not recover the affected thread.

[kevvykevwin]

Update: this now affects two separate threads.

The replacement thread was created after Codex CLI was updated:

• Codex update time: 2026-08-26 14:19 MDT
• Replacement thread creation: 2026-08-26 15:36 MDT
• Recorded thread cliVersion: 0.150.0
• Failure time: 2026-08-26 16:18 MDT
• Trace ID: f8fc6550df73d17f652dee0ec5dbc30b
• Thread ID: 2ecacceb-eaa5-4a7d-a132-3328f13a2a0d

The replacement thread therefore did use Codex CLI 0.150.0. It later failed
with the same schema error:

SchemaError: Expected "started" | "interacted" | "interrupted"
at ["thread"]["turns"][0]["items"][23]["kind"]

This suggests a protocol compatibility mismatch between Codex CLI 0.150.0
and the schema bundled with T3 Code Alpha 0.0.34. Creating a new thread is
only a temporary workaround.

[Yachint]

I’m seeing the same issue with T3 Code 0.0.34 and Codex CLI 0.150.0. The thread fails to resume with the identical subAgentActivity.kind schema error. The underlying thread is intact, I was able to recover and continue it using codex resume --all.

[t3dotgg]

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

The PR adds Codex's completed subagent activity kind to the exact schemas used to decode resumed thread history. It also updates the schema generator and tests so the fix remains in place after regeneration.

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 rejected value from the decoder error, and we can reopen it.