Desktop app: effort picker silently drops 'max', shows 'extra effort' while ultracode is active, and /effort is unavailable in app sessions

Environment

• macOS 26.2 (25C56), Apple Silicon
• Claude desktop app 1.11187.4 (auto-updated 5-6 June)
• Bundled Claude Code CLI 2.1.165 (standalone terminal CLI 2.1.168 shows the same schema behaviour)
• Max plan, model claude-opus-4-8[1m]

Three related effort-control defects in the desktop app. Together they make max/ultracode effectively uncontrollable and unverifiable in the app, which is painful for teams that lean on ultracode heavily.

1. Selecting Max in the effort picker is silently discarded

Clicking Max in the app's effort picker does nothing; the picker snaps back to the previous level with no error.

From inspecting the bundle: the picker applies live changes via applyFlagSettings, whose effortLevel schema is enum(["low","medium","high","xhigh"]).optional().catch(void 0) — "max" fails validation and .catch(void 0) discards it silently. The spawn/resume path accepts --effort max fine (a resumed session shows it in its process args), so it is only the live-change path that drops it. The persistence path has the same 4-value enum, so Max also cannot survive into the persisted setting.

Expected: either accept max (live enum already allows it: low | medium | high | xhigh | max) or show why it was rejected. Silent no-op is the worst outcome.

2. Picker label reverts to "extra effort" while ultracode is actually active

Selecting Ultracode works: the engine session receives --settings {"ultracode":true} (verified in the live process args) and the ultracode activation reminder is injected. But the picker label then displays "extra effort" (the underlying xhigh), so users conclude the choice reverted and that ultracode is off. Combined with effort being session-only, this destroyed our team's confidence that ultracode works at all in the app.

Expected: label should read "ultracode" while the session flag is active.

3. /effort is unavailable in desktop app sessions

Typing /effort in the app's input returns "/effort isn't available in this environment", so there is no typed fallback for max or ultracode in the app (it works fine in the terminal CLI). With bug 1, Max is simply unreachable in the desktop app.

Workarounds found (for anyone else hitting this)

• The "ultracode" keyword in a prompt still force-opts that turn into Workflow orchestration (verified against the bundled 2.1.165 binary headless).
• Terminal sessions: /effort max / /effort ultracode work as documented, session-scoped.