[Bug]: New threads in the same project do not preserve the last-used model and working-mode settings #6508

Activity

1. relatedcode commented on Aug 29, 2026

   

   relatedcode

   on Aug 29, 2026

   More actions

   T3 Code starts every new Codex thread at Low. My ~/.codex/config.toml already has model_reasoning_effort = "high". Changing the composer to High does not provide a reliable global default. This happens with GPT-5.6-Sol on macOS.

   👍React with 👍1Reacted by Vitaly Gashkov
2. imadtg commented on Aug 30, 2026

   

   imadtg

   on Aug 30, 2026

   Last edited by imadtg

   More actions

   I’m seeing what appears to be the same web-client model-selection issue through T3 Connect.

   Environment:

   • Linux
   • T3 server running as the background t3code.service
   • Connected through T3 Connect and app.t3.codes
   • Server version: 0.0.37-nightly.20260830.1227
   • Codex and OpenCode enabled

   Concrete evidence from the live server database:

   • The selected project has an explicit new-thread default of codex / gpt-5.6-sol.
   • A thread created in that same project was submitted with opencode / opencode/big-pickle and the OpenCode build agent.
   • The thread.created and thread.turn-start-requested events already contained the OpenCode selection, so this was not a server-side provider fallback.
   • Other nearby threads in the same project were correctly created with gpt-5.6-sol, with reasoning levels medium and high.

   Reproduction pattern:

   1. Use gpt-5.6-sol with reasoning medium or high.
   2. Move between projects or previously used OpenCode/Big Pickle threads.
   3. Return to a project whose configured default is Codex.
   4. Press Ctrl+Shift+O.
   5. The new thread can be created with opencode/big-pickle, even though the project default is Codex and the visible composer may show Codex.

   The behavior suggests that the web client’s active-provider/sticky-selection state can become stale or diverge from the visible composer selection. The shortcut then submits the stale provider/model when creating the thread.

   No server crash, provider outage, or database corruption was observed. Reselecting Codex immediately before creating the thread is a temporary workaround.

   This may be related to #5796 and #5421 as well.

   — Investigated by GPT-5.6 Sol via Codex triage

   👍React with 👍1Reacted by Vitaly Gashkov
3. elmarbeckmann commented on Sep 2, 2026

   

   elmarbeckmann

   on Sep 2, 2026

   More actions

   Still hitting this on 0.0.39-nightly.20260902.1253, and I went digging in the bundle to see why it is so inconsistent.

   New threads don't really "forget" the mode — they only ever remember it when there is something to carry it from. The code picks carryRuntimeMode ?? DEFAULT_RUNTIME_MODE, where the carry source is the composer, the shell, or the draft you came from, and DEFAULT_RUNTIME_MODE is hardcoded to "full-access". So starting a thread from an existing one keeps my choice, and starting a fresh one silently drops back to Full access. That explains the "sometimes it sticks, sometimes it doesn't" feeling in this thread. There's no defaultRuntimeMode key in settings.json or client-settings.json either, so there is nothing to pin it down with.

   Setting it on the Claude side doesn't work as an escape hatch: T3 launches the CLI with an explicit --permission-mode, and that flag outranks permissions.defaultMode in ~/.claude/settings.json. #7577 describes that precedence problem from the other direction.

   What makes this more than an annoyance for me is which mode we land in. My work machine has cloud credentials, kubectl contexts for production clusters and push access to our repos, and the mode I get by accident is the one that skips both the classifier and the sandbox. Auto costs me an occasional prompt and keeps those checks. Remembering the last used mode per project, which is what this issue asks for, would be enough for me. #2662 and #4916 asked for a global default, which would also cover the first thread in a brand-new project.
4. kinorai commented on Sep 13, 2026

   

   kinorai

   on Sep 13, 2026

   More actions

   Still present on server 0.0.40, and the mobile web client hits it on every new thread.

   useHandleNewThread.ts builds the carry chain from the route you are on:

   const carryRuntimeMode =
     carrySourceComposer?.runtimeMode ??
     carrySourceShell?.runtimeMode ??
     carrySourceDraft?.runtimeMode ??
     null;
   // ...
   runtimeMode: carryRuntimeMode ?? DEFAULT_RUNTIME_MODE,

   All three sources derive from getCurrentRouteTarget(). On mobile the normal entry point is the project/thread list, where the route target is neither server nor draft, so all three are null and every new thread lands on DEFAULT_RUNTIME_MODE = "full-access". Opening an Auto thread first and creating the new thread from inside it carries Auto correctly, which matches the analysis above.

   Repro (mobile web, app.t3.codes):

   1. Set a thread to Auto, send a turn.
   2. Go back to the project list.
   3. New thread -> Full access.

   Server-side DEFAULT_RUNTIME_MODE is "full-access" in src/persistence/Migrations and in the ThreadCreatedPayload / thread.turn.start schema defaults, so the client fallback is the only place a user preference could apply today. The settings schema has defaultThreadEnvMode and newWorktreesStartFromOrigin but no runtime-mode sibling.
5. Jardo-51 commented on Sep 15, 2026

   

   Jardo-51

   on Sep 15, 2026

   Contributor

   More actions

   +1 for this. I have separate Claude providers for work and personal projects. Right now the web app is remembering a "global" last-used provider. Which means that when I start a new thread on a work project I select the work provider which gets remembered, and later when I start a new thread on a personal project, I can accidentally use the work provider on that personal project, and vice-versa.

   Also the mobile app should be consistent with this behavior (which it currently is not).
6. t3dotgg commented on Oct 21, 2026

   

   t3dotgg

   on Oct 21, 2026

   Member

   More actions

   Note

   🤖 Claude Opus 5.5 responding on behalf of Theo

   Thanks for the report. One part of this is fixed on main in #6011, #9164 and #11346. Please test on the nightly built from main on 2026-10-21, or on the next stable release. One part is still open: per-project last-used provider/model options and working-mode memory across entry points. If that part still matters to you, please open a new issue for that part only.
7. t3dotgg

   closed this as completedon Oct 21, 2026
8. juliusmarminge commented on Oct 22, 2026

   

   juliusmarminge

   on Oct 22, 2026 – with GitCafe Production

   Member

   More actions

   Reproduced the remaining runtime-mode case in the web dev app on 3b95e7831b: selected GPT-6.1-Sol, High reasoning, and Auto in a new thread, sent a message, then created another thread in the same project through the breadcrumb. The new composer preserved GPT-6.1-Sol and High but reset Auto to Full access. Tested on Linux in Chromium with isolated copied state.

   

   
9. t3dotgg

   reopened this on Oct 22, 2026
10. t3dotgg commented on Oct 22, 2026

    

    t3dotgg

    on Oct 22, 2026

    Member

    More actions

    Note

    🤖 Claude Opus 5.5 responding on behalf of Theo

    Reopening: our earlier close left the remaining part with nothing tracking it, and it is reproduced on current main. A new thread started from the breadcrumb keeps the model and reasoning level but resets Auto to Full access.