[BUG] Remote Control: new-session composer omits "Ultracode" from the effort picker (present in-session and on other clients)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When starting a new session against a Remote Control environment (claude remote-control, spawn mode worktree) from claude.ai/code, the effort picker in the composer tops out at "Max", "Ultracode" is not listed for any model.

The same web UI offers Ultracode once the session is running, and selecting it there works. The reporter also sees Ultracode offered at start on the Claude mobile app and in a local (non-remote) session. So the omission is specific to the new-session composer of a Remote Control environment.

Impact: effort and orchestration cannot be chosen before the first message. For planning, spec and analysis work, where the choice matters most, the session has to be started at another tier and then switched with a separate /effort ultracode message.

Analysis on the host binary (2.1.222)

• effortLevel is persisted against enum(["low","medium","high","xhigh"]). ultracode is a separate session-scoped boolean: "Enable ultracode for the session: xhigh effort plus standing dynamic-workflow orchestration. Session-scoped, typically provided via --settings or the apply_flag_settings control request".
• Applying it goes through the control channel (caps.controlChannel === true), which only exists once a session exists. That is consistent with the entry appearing only after the session has started.
• The bridge registration payload (registerBridgeEnvironment) carries no effort capability at all: {dir, machineName, branch, gitRepoUrl, maxSessions, spawnMode, verbose, sandbox, bridgeId, workerType, environmentId, reuseEnvironmentId, apiBaseUrl, sessionIngressUrl}.
• The bridge forwards only --permission-mode to spawned sessions (scriptArgs is just the pinned binary path), so --effort ultracode or --settings '{"ultracode":true}' on the host never reach the session. There is no host-side workaround.

The only server-side lever is "ultracode": true in ~/.claude/settings.json, which then applies to every session unconditionally, not a per-session choice.

Related, but not duplicates

• #71774 and #80301 are about persistence (settings.json discarding max/ultracode).
• #51549 (closed) covered effort control in remote sessions generally; that does now work in-session.

This report is about one client surface omitting an entry that another surface of the same client offers.

What Should Happen?

The effort picker in the new-session composer of a Remote Control environment should list "Ultracode", exactly as it is listed once the session is running and as it is offered at start on the mobile app and locally. A Remote Control session should be able to start in ultracode from its first message.

If starting a remote session in ultracode is intentionally unsupported, then the in-session picker and the other clients should not offer it either, the current behaviour is inconsistent between surfaces of the same product, which is what makes it read as a bug rather than a limitation.

Error Messages/Logs

No error is produced, the "Ultracode" entry is simply absent from the picker, and nothing is logged on the host.

For contrast, the in-session path succeeds and reports:

  Set effort level to ultracode (this session only): xhigh + dynamic workflow orchestration

Steps to Reproduce

1. On a Linux server, start a Remote Control host:

``
claude remote-control --name my-host --spawn worktree --permission-mode auto
``

1. From another machine, open claude.ai/code and select that Remote Control environment.
2. In the new-session composer, before sending anything, with model Opus 5, open the effort picker.

→ The highest entry is "Max". "Ultracode" is not listed.

1. Send any message so the session actually starts.
2. Open the effort picker again in the now-running session.

→ "Ultracode" is listed, is selectable, and works.

For contrast, on the same account: the Claude mobile app and a local (non-remote) session do offer Ultracode at start.

Environment

• Claude Code host: 2.1.222 at time of reproduction, since updated to 2.1.227, the changelogs for 2.1.223–2.1.227 contain no change to the effort picker or to remote effort handling
• Client: claude.ai/code in the browser, Remote Control environment
• Node 22.22.1, Ubuntu, x86_64
• Model: Opus 5
• ~/.claude/settings.json: effortLevel: "high", no ultracode key, permissions.defaultMode: "auto"
• tengu_workflows_enabled is true for this account, and Ultracode works in-session, so this is not a dynamic-workflows entitlement problem.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.227 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Non-interactive/CI environment

Additional Information

Why this is not a duplicate

• #71774 - Persist ultracode/max effort as a persistent default for new sessions: asks for a persisted default in settings.json. This report is not about persistence; it is about an entry missing from a picker on one client surface while being present on another.
• #80301 - effortLevel in settings.json silently discards "max" and "ultracode": same underlying fact (the persisted enum is a strict subset of the runtime tiers), different symptom.
• #51549 (closed) - Expose effort level control to Remote Control sessions: that shipped; /effort does work in a running Remote Control session, which is precisely the contrast that makes the composer's omission visible.

Current workaround

Send /effort ultracode as the first message of the Remote Control session, then the actual prompt. It applies before any work is done, so nothing is lost except one round trip - but it is not discoverable, and a user who instead types the word "ultracode" into the prompt gets only the Workflow keyword trigger, not xhigh effort.

The alternative, "ultracode": true in ~/.claude/settings.json, is all-or-nothing for every session and therefore not a substitute for the picker entry.

Note on the version

Reproduced with host 2.1.222; the host has since been updated to 2.1.227 (latest at time of filing). The affected surface is the claude.ai web composer rather than the CLI, and the changelogs for 2.1.223–2.1.227 list no change to effort handling or to the Remote Control picker.

Screenshots

No Ultracode selectable initially

<img width="808" height="163" alt="Image" src="https://github.com/user-attachments/assets/fd2ebd43-decf-44fd-803c-81d557982683" />

Ultracode selectable after first message

<img width="813" height="183" alt="Image" src="https://github.com/user-attachments/assets/0c9bae57-699c-4e5e-aab9-0874eaaf39b4" />