/effort with unknown arg silently sets level to max instead of rejecting

Summary

Passing an unrecognized argument to /effort (e.g. /effort auto) silently sets the effort level to max instead of rejecting the input or opening the picker. The confirmation message does not echo the input value, so it's easy to miss that the arg wasn't accepted.

Environment

• Claude Code: 2.1.119
• Platform: macOS (Darwin 25.4.0)
• Model: Opus 4.7

Repro

1. /effort auto → output: Effort level set to max
2. /effort low → output: Set effort level to low: Quick, straightforward implementation with minimal overhead (works correctly)
3. /effort (no arg) → opens the picker UI showing valid values: low | medium | high | xhigh | max (works correctly)

So /effort correctly handles known values and the empty-arg case, but unknown args fall through to max with no warning.

Expected

Either reject the unknown arg with an error listing valid values, or open the picker (same behavior as /effort with no arg).

Actual

Unknown args resolve to max. The confirmation line Effort level set to max looks identical to a successful /effort max, masking the parser miss.

Why this matters

Silent fall-through to the highest effort level changes model behavior and cost without the user realizing the arg wasn't accepted. A user typing /effort auto (a plausible value to try) ends up at max and won't know unless they check the status line.

Suggested fix

Validate against the allow-list (low | medium | high | xhigh | max) before applying. On mismatch, print the valid set and either no-op or open the picker. Echoing the resolved value in the confirmation (e.g. Set effort level to <value>) would also surface this class of bug to users.