[Bug]: Switching compatible Codex accounts with shared CODEX_HOME uses portable handoff instead of native thread resume

[WISSAM492]

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. Use T3 Code nightly 0.0.46-nightly.20261005.2702.

2. Use Codex CLI 0.160.0.

3. Configure two authenticated Codex provider instances using the documented shared-home setup:

   Instance 1:

   • CODEX_HOME: ~/.codex
   • Shadow home: empty

   Instance 2:

   • CODEX_HOME: ~/.codex
   • Shadow home: ~/.codex_2nd

4. Fully restart T3 Code after saving the provider settings.

5. Create a new T3 thread using Instance 1.

6. Complete several turns on Instance 1.

7. In the same T3 thread, switch the Codex account/provider instance to Instance 2.

8. Send another message.

9. Ask Instance 2, without using t3_thread_read, whether it received the original conversation natively and what history it received.

This reproduces consistently for me.

Expected behavior

Because both Codex instances share the same CODEX_HOME, switching between them should resume the same native Codex thread/session.

The target account should continue using native Codex thread resume, preserving the full provider-native conversation state.

A compatible Codex account switch should not silently fall back to a portable/context handoff.

Actual behavior

After switching from Instance 1 to Instance 2, the target Codex instance receives a T3 context handoff instead of appearing to resume the same native Codex thread.

On a fresh short test thread, the target explicitly reported:

"This chat started with a context handoff containing 13 intact items and 0 omitted items..."

On a longer thread, the target reported that only a selected subset of history was included and that additional items were omitted.

The T3 UI still shows one continuous conversation, but the target Codex instance is receiving handoff context rather than full native continuation.

Impact

Major degradation or frequent failure

Version or commit

T3 Code: 0.0.46-nightly.20261005.2702

Environment

• OS: Ubuntu Linux - T3 Code desktop app - T3 Code: 0.0.46-nightly.20261005.2702 - Codex CLI: 0.160.0 - Provider: Codex - Two separately authenticated ChatGPT/Codex accounts Provider configuration: Instance 1: - CODEX_HOME: ~/.codex - Shadow home: empty Instance 2: - CODEX_HOME: ~/.codex - Shadow home: ~/.codex_2nd

Logs or stack traces

No relevant stack trace observed. The failure is behavioral: the target Codex instance reports receiving a T3 context handoff after the account switch.

Screenshots, recordings, or supporting files

Screenshot 2026-10-07 014223.png
Screenshot 2026-10-07 014309.png
Screenshot 2026-10-07 014444.png
Screenshot 2026-10-07 014401.png

Workaround

Avoid switching Codex provider instances within an important long-running thread.

Staying on the same Codex instance preserves the current native session behavior. Using the account switch currently risks falling back to a context handoff.

[WISSAM492]

Additional context after reproducing this again:

The current Codex docs explicitly state that compatible accounts can continue the same thread, and that a shared CODEX_HOME + shadow home setup shares Codex sessions/configuration.

This also appears related to #4766, which documented loss of the provider-native resume cursor when switching between compatible provider instances and was later closed by Orchestrator V2 / #2829.

The important difference from #8259 is that I am NOT seeing an already has an active writer failure here. The V2 switch succeeds, but the target Codex instance appears to receive a T3 context handoff instead of native continuation.

If useful, I can collect provider/session logs or native Codex thread IDs before and after the switch to verify whether thread/resume or thread/start is actually being used.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Confirmed on current main: with two Codex instances sharing the same CODEX_HOME (auth-overlay / shadow home on one of them), a mid-thread account switch is supposed to resume the same native Codex thread, not inject a T3 portable context handoff. Your setup matches the documented multiple CLI logins table, and the symptom ("context handoff containing N intact items") is a real portable-handoff path.

Intended path

• Shared home → same continuationKey (codex:home:<resolved path>) in CodexHomeLayout / codexContinuationIdentity.
• ProviderSessionTransitionPolicy then returns restart_and_resume when the instance changes but the continuation key matches.
• Orchestrator canResumeAcrossInstances should rebind the existing provider thread (keep nativeThreadRef), detach the old session, skip prepareProviderHandoff, and let Codex thread/resume continue the native conversation.

Where it still falls into portable handoff

Two concrete gaps on main explain falling through to a full T3 handoff instead:

1. Queued start ignores an already-applied selection — In the queued-run starter, canResumeAcrossInstances only runs when thread.modelSelection still differs from the queued run's selection. After thread.model-selection.set / provider.switch, those already match, so the switch plan is skipped and a portable handoff is prepared for the prior instance's runs. The live message.dispatch path already documents this case ("Account overlays share native history… classify against the native thread's owner") and forces the plan current instance from activeProviderThread.providerInstanceId. The queued path never got that fix.

2. Resume-failure fallback always materializes a full handoff — Even when Orchestrator does take the native-resume path, ProviderTurnStartService catches a failed session.resumeThread / thread/resume, starts a fresh thread/start, and calls prepareProviderHandoff with full_thread_summary (provider_resume_fallback). That produces exactly the "intact / omitted items" preamble you saw. If you can grab server logs around the switch, look for Provider resume failed; attempting a fresh native session and compare native Codex thread IDs before vs after — that would confirm this fallback vs the queued-plan gap.

Related (not duplicates)

• #4766 (closed) — older compatible-instance native-context loss; V2 / feat(orchestrator): introduce new orchestrator #2829 era.
• #8259 — already has an active writer (you are not hitting this).
• #11136, #14798, #15476 / #15477, #15997, #16000 — nearby account/instance switch and handoff behavior.

No open fix PR found. Workaround of avoiding mid-thread instance switches is correct until this is fixed.

Labeling bug + via-triage.