Flag-conflict error names the flag you actually used

The cloud-session conflict error now blames --environment, the flag you actually typed.

You'll noticeTier: how much it should matter to you

2Useful: my rating, 1 to 5

2Signal: worth watching, 1 to 5

CLIArea: what it touches

Bug FixesKind: in v2.1.224, 07 Aug 26

Bug FixesSection of the release

What

When a self-hosted pool is selected, the cloud-session flag conflict error now blames --environment rather than --cloud, and drops the claude.ai/code reattach hint that did not apply.

Evidence

--environment

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

Read from

Names in the bundle--environment

See this entry in the whole of v2.1.224 →

The build it came inv2.1.224

7 Aug 2026 · 352 entries, this one is #246.

Use it now44
You'll notice168
Nothing to try yet41
Under the hood99

Either side of it

v2.1.223Older
v2.1.225Newer

Open the release →

Names in this entry

cli--environment
Create a new cloud session that runs on the self-hosted environment with the given ID. Environment IDs start with ccpool_. See --environment dispatch behavior for dispatch behavior and the flag combinations it rejects. Requires Claude Code v2.1.224 or later
cli--cloud
With a task description, create a new cloud session. With a session ID (session_... or cse_...) or a claude.ai/code URL, queue a message into that existing session instead, with -p. See send a follow-up message.

Is this right?

Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.

v2.1.229 Whitespace-only prompts are rejected for --cloud and --environment
Both mention environment
v2.1.269 New 'auto_mode_environment' config field
Both mention environment
v2.1.283 Session metadata can now include the host environment
Both mention environment