[Bug]: ProviderAdapterProcessError: Provider adapter process error (codex) for thread ...: session ... is archived. Run `codex unarchive ...` to unarchive it first.

[delu999]

Before submitting

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

Area

Not sure

Steps to reproduce

1. Start a chat with Codex in T3 Code.
2. Archive it in ChatGPT.
3. Send a new message in the same chat in T3 Code. The error appears.

Expected behavior

The thread should resume normally and accept the new message.

Actual behavior

this error toast appears

Impact

Minor bug or occasional failure

Version or commit

No response

Environment

No response

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Triage

Confirmed bug. Archiving the conversation in ChatGPT archives the Codex CLI session (rollout moves to archived_sessions). The next send in T3 tries to resume that session and Codex refuses:

session … is archived. Run \codex unarchive …` to unarchive it first.`

T3 wraps that as ProviderAdapterProcessError and shows the toast. It does not unarchive and retry.

This is not T3 thread archive.

Where it breaks

• apps/server/src/provider/Layers/CodexSessionRuntime.ts — openCodexThread() does thread/resume, then only falls back to a fresh thread/start for missing-thread errors (not found, no rollout found, …). “is archived” is not in that list (good — a fresh start would drop history), and there is no unarchive path.
• apps/server/src/provider/Layers/CodexAdapter.ts — startSession maps the failure to ProviderAdapterProcessError.
• The generated Codex app-server protocol already has thread/unarchive ({ threadId }). T3 handles thread/archived / thread/unarchived notifications but never calls thread/unarchive.

Not duplicates

• [Bug]: Usage page never scans Codex archived_sessions/, so archived sessions' usage silently disappears #7090 — usage page skips archived_sessions/
• [Bug]: Archiving the thread you are in permanently wedges that project's new-thread draft (archived_at read-model asymmetry) #6128 — T3-archive of the open thread wedges the project draft
• fix(server): treat a missing Codex rollout as a recoverable resume error #6671 — missing rollout → recoverable fresh start (wrong for this case)

Suggested fix

On thread/resume failure that looks like an archived session (is archived / codex unarchive):

1. thread/unarchive with the resume-cursor provider thread id
2. retry thread/resume
3. only then fail

Do not treat “archived” as a recoverable missing-thread error.

Workaround

Run codex unarchive <session-id> from the toast, then resend in T3.

Severity

Minor / occasional — only after ChatGPT (or Codex) archives the session. Accepting as a Codex resume-path bug.