[Bug]: Self model configuration can stop its own run without continuing#15300

Triage

Thanks for the clear report, @PixPMusic! This looks like a real bug, and it's separate from the open #15195. That one is about the composer keeping a stale model after another client changes it. Here, the running turn is the one calling t3_thread_configure.

t3_thread_configure only runs while the caller owns an active run (assertLiveCaller in apps/server/src/mcp/threadAccess.ts). The handler then sends the normal next-turn selection command (provider.switch when the instance changes, thread.model-selection.set otherwise) and returns just { sequence }.

Instance change (codex to codex_alt, same Codex home). These instances share a continuation key, so decideProviderSessionTransition plans restart_and_resume, and ProviderSwitchService releases the live session. dispatchThreadMutation saves the new selection and queues that detach, but it doesn't start another attempt. Because Codex sessions allow multiple threads, the detach calls interruptTurn on the turn that's still running. The run is still running on that attempt, so finalization treats the interrupt as the end of the run and writes "Run interrupted by user" (makeInterruptResultTurnItem in RunExecutionService.ts). Nothing replays the unfinished request, so the poem never runs and you have to send another message.

Same instance (Luna to Sol). Codex treats every selection change as apply_on_next_turn, which becomes switch_model_in_session and releases nothing. The saved selection updates and the tool reports success, but the active turn keeps running on Luna. Reading the saved configuration back won't show that this request actually ran on Luna rather than Sol.

Likely fix area

Codex can't retarget the turn that's running the tool, so a few directions are possible:

• The tool could report that limit for a self-configure call and leave the current session and run alone, with the change applying from the next turn.
• Alternatively, the unfinished request could be replayed under the new model. Today the selection-restart path only does that when a new message arrives, not from a configure call, so this would be a separate choice.

A maintainer will decide on the fix direction.

Observed the same failure in a live Linux session on T3 Code 0.0.46-nightly.20261007.2787 on 2026-10-08. This occurrence switched between different provider drivers, from Codex to OpenCode.

The running coding agent was preparing a scheduled follow-up and tried to follow a configured GPT-5.4/high automation default. It changed the active conversation's provider/model itself, although the user had not requested that conversation switch.

The durable timeline and server logs show:

• At 00:41:49.347 UTC, the Codex agent's own t3_thread_configure call completed successfully. Its selection was instanceId: opencode, model: opencode/gpt-5.4, with variant: high and agent: build. The previous run was on provider instance codex, model gpt-6.1-sol.
• Its immediately following schedule_task call failed at 00:41:49.596 UTC with OrchestratorMcpFailure, code parent_not_active, and message The calling provider no longer owns an active thread run. No scheduled task was created.
• At 00:41:49.994 UTC, the original Codex run ended as interrupted. The timeline said Run interrupted by user, although this interruption followed the agent's successful self-configuration call, not a user Stop action. There was no automatic continuation.
• A subsequent user message selected the now-saved OpenCode configuration. That attempt additionally encountered a separate provider-start error, spawn <opencode binary> EACCES, in the server log. The user then stopped that attempt before provider start.

The audit trail identifies OpenCode as the selected destination, with no Cursor run in this conversation. The direct failure chain was successful self-configuration, loss of active-run ownership, rejection of the next MCP call, and an interrupted run with no continuation. This reproduces the issue on the October 7 nightly as well.

Additional recovery problem: the user then tried to switch back through the model picker. The UI disabled Codex and displayed exactly: "Codex is unavailable in this thread. Start a new thread to switch providers." The screenshot showed OpenCode models as the available choices. This left the user unable to restore the original provider through the picker after the agent-initiated switch.

Restoring the same existing thread through t3_thread_configure with its original Codex selection succeeded. However, the subsequent continuation failed with Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated. A /compact request was then accepted and the timeline showed Compacting context. The picker prohibition and the thread control API disagree about whether this thread can switch back; restoring the provider selection alone did not resume the unfinished work.

The compaction run subsequently received an explicit interrupt request before a completed compaction appeared in the timeline. It ended interrupted, so restoration of the provider selection is confirmed, but successful continuation is not yet confirmed.

Still seeing this on 0.1.1-nightly.20261020.3399 with Orchestrator V2, on Linux (2026-10-20), switching from Codex GPT-6.1-Sol to Cursor GPT-5.4.

After the agent's thread-model change, the run ends with Run interrupted by user. The timeline shows Context handoff pending and the picker disables Codex with Codex is unavailable in this thread. Start a new thread to switch providers.

Read-only inspection confirms the saved selection is cursor / gpt-5.4, but activeProviderThreadId still points to Codex and no Cursor run has started. The selection changes, but the unfinished task does not automatically continue, and the picker blocks switching back. This persists after the V2 rollout.