# \[Bug\]: Self model configuration can stop its own run without continuing · Issue \#15300 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/15300)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: backlog

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/15300)

---

### Area

apps/server

### Steps to reproduce

1. Configure two Codex provider instances (`codex` and `codex_alt`). Both can use the same existing Codex installation and home.
2. Start a thread on `codex` with GPT-6-Luna.
3. Ask: “Switch this thread to GPT-6.1-Sol using provider instance codex_alt and low reasoning with t3_thread_configure, then write a four-line poem about changing your mind. Do not edit files or use subagents.”
4. Let the agent call `t3_thread_configure`.

### Expected behavior

The thread continues the unfinished request under the selected model. If the provider cannot do that safely, the tool reports the limitation without stopping the current run.

### Actual behavior

The selection is saved, but the active provider session is detached. The run ends with “Run interrupted by user” even though no one pressed Stop. There is no continuation and no poem; another user message is required.

The tool dispatches the ordinary selection command, which can release the current session without scheduling another attempt. A separate same-instance check on this commit saved Sol while the active run completed on Luna, so reading the saved configuration does not prove that the requested work ran under the new model.

### Environment and impact

Reproduced on `main` at `cfdff56f7b3c9c931ae368224041aa14825649fd`, macOS 26.7, Node 26.10.0, the T3 Browser panel, and a real Codex provider. The development server used isolated state. This loses the remainder of the active task until the user intervenes.

The original report showed same-instance model changes interrupting an installed build. On the current base, the session-detaching case above reproduces the interruption; the same-instance case instead keeps the old active model.

### Evidence

[Before recording](https://github.com/PixPMusic/t3code/releases/download/model-tool-continuation-evidence-20261003/before.mp4)

![Tool-triggered interruption without a poem](https://github.com/PixPMusic/t3code/releases/download/model-tool-continuation-evidence-20261003/before.png)

### Workaround

Manually select the intended provider/model before sending another message. The stale composer selection is separately tracked in #15195.

- [x] Searched existing issues and PRs for the same tool failure.
- [x] Included a current-base reproduction and recording.