### Preflight Checklist - [x] I am using the latest version of Claude Code (v2.1.222) - [x] I searched existing issues. Related but distinct: #66266 (reverts when switching **chats**), #71774 (does not persist across **new sessions**), #78718 (`dynamicWorkflowsEnabled` hides the **display**). This report is about `/model` clearing it **within one live chat**, which none of those cover. ### What's Wrong Running `/model` inside a session that has Ultracode enabled silently turns Ultracode off.

[BUG] /model silently disables Ultracode in a live session

Status Open

Reported on v2.1.222

Maintainer reply None cached

Activity 4 comments · opened Aug 5, 2026

Preflight Checklist

[x] I am using the latest version of Claude Code (v2.1.222)
[x] I searched existing issues. Related but distinct: #66266 (reverts when switching chats), #71774 (does not persist across new sessions), #78718 (dynamicWorkflowsEnabled hides the display). This report is about /model clearing it within one live chat, which none of those cover.

What's Wrong

Running /model inside a session that has Ultracode enabled silently turns Ultracode off. The composer footer goes from Opus 5 Ultracode to Opus 5 alone, with no message saying the setting was dropped.

This is not only a display problem. In the affected session the assistant went on receiving no ultracode system-reminder on subsequent turns, which is what an assistant sees when the mode is genuinely off — so the session state itself appears to be cleared, not just its label. That matters because the assistant's behaviour is gated on that reminder: it will quietly stop defaulting to multi-agent workflows while the user believes Ultracode is still on.

Ultracode is session-only state with no representation in settings.json, so nothing restores it and nothing reports the loss. The user only finds out by noticing the footer changed.

What Should Happen

Changing the model should leave Ultracode alone. If there is a genuine reason it cannot survive a model change, the client should say so explicitly at the moment it happens rather than dropping it silently.

Steps to Reproduce

Open a chat in Claude Code Desktop and enable Ultracode. Footer shows Opus 5 Ultracode.
Run /model and select a model (reproduced selecting Opus 5, including when it is already the active model).
Observed: footer shows Opus 5 with no Ultracode; subsequent turns carry no ultracode system-reminder.
Expected: Ultracode remains enabled, or the client states that it was cleared.

Claude Code Version

2.1.222 (native install)

Platform

Claude Code Desktop, Windows

OS

Windows 11 Pro 10.0.26200

Additional Info

grep -i ultracode across ~/.claude/settings.json and the per-config-root settings.json files returns nothing, confirming the mode is never written to disk and so cannot be recovered after it is cleared.

The common thread across this, #66266 and #71774 is that Ultracode lives only in volatile per-view state, so any state transition can drop it and none of them announce it. A single durable owner for the flag would close all three.

View original on GitHub ↗

3 Comments

wshallwshall · 1 month ago

Still relevant, and still distinct from the three neighbours listed in the report: #66266 is switching chats, #71774 is persistence across new sessions, #78718 is the display rather than the state. This is /model clearing Ultracode inside one live chat.

Two related threads worth seeing together: #72435 asks for a persistent default, which would limit how much each occurrence costs, and #77003 notes the VS Code extension has no Ultracode indicator at all, so there the same clearing happens with nothing on screen to reveal it.

wshallwshall · 1 month ago

Still open. To keep this separate from the neighbouring Ultracode issues: #66266 is about switching chats, #71774 is about new sessions, and #78718 is about dynamicWorkflowsEnabled hiding the display. This is /model clearing the mode inside one live chat, which none of those cover.

The part that makes it more than a display bug is what the assistant sees afterward. In the affected session it stopped receiving the ultracode system reminder on subsequent turns, which is what an assistant sees when the mode is genuinely off. So the session state appears cleared, not just its label, and the assistant quietly stops defaulting to multi-agent workflows while the user believes the mode is still on.

Ultracode has no representation in settings.json, so nothing restores it and nothing reports the loss. #72435 asks for the persistent setting that would at least make it recoverable.

wshallwshall · 21 days ago

Still open. #75927, where the Ultracode setting was dropped when the agents view dispatched a session, was closed as completed. That was a case of the setting not being carried through one code path. /model may be a second path with the same gap.

#90744, from another user, describes Ultracode as a session-only flag that cannot be observed. This issue is one concrete trigger that turns it off inside a live chat, with no message to the user and no reminder to the model.

Showing cached comments. Read the full discussion on GitHub ↗