CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 silently disables auto mode at session start (no cause shown in interactive/Desktop; mid-session toggle bypasses it) — 2.1.216

Summary

CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 (set via the env block of ~/.claude/settings.json) silently makes auto mode unavailable at session start. The user only sees the generic banner:

このセッションでは自動モードを使用できません。代わりに権限をリクエストします。 (Auto mode is not available in this session. Permissions will be requested instead.)

Nothing indicates that the env-scrub setting is the cause. The explanatory warning (⚠ Permission mode forced to default — CLAUDE_CODE_SUBPROCESS_ENV_SCRUB is set (allowed_non_write_users hardening)…) is only printed in headless -p runs, never in interactive CLI or Desktop sessions.

This is a follow-up to #51258 ("CLAUDE_CODE_SUBPROCESS_ENV_SCRUB should not override permission mode"), which was closed as stale/NOT_PLANNED. That issue covered --dangerously-skip-permissions / bypassPermissions; this report adds that auto mode is affected too, that the behavior also applies to the Desktop app (it launches the bundled runtime as a subprocess, so the same forcing kicks in), and that it still reproduces on the current release.

Environment

• Claude Code CLI 2.1.216 (also reproduced on 2.1.202) — Windows 11 Home 10.0.26200
• Claude Desktop app 1.22209.3.0, bundled runtime 2.1.215
• Auth: claude.ai subscription (Max), model: Fable 5 (also reproduces with Opus — model-independent)
• ~/.claude/settings.json env block contains "CLAUDE_CODE_SUBPROCESS_ENV_SCRUB": "1"

Steps to reproduce

1. Put "env": { "CLAUDE_CODE_SUBPROCESS_ENV_SCRUB": "1" } in ~/.claude/settings.json.
2. Start a new session (Desktop app or CLI) with auto mode selected as the starting mode.
3. Session starts with the "auto mode is not available in this session" banner and falls back to requesting permissions (default mode).

Controlled A/B on the same machine, same account, same model:

• CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 → auto mode rejected at every session start (any model: Fable 5, Opus).
• Flip the same setting to "0" (only change) → new session starts in auto mode normally.

Additional observations

• Mid-session toggle bypasses the check: switching to auto via the mode selector / Shift+Tab after session start succeeds even while the setting is 1. So the forcing is only enforced at startup, which makes the restriction look inconsistent and made root-causing much harder.
• No cause surfaced in interactive/Desktop sessions: the banner gives no hint. We initially misattributed this to model support and then to the v2.1.158–v2.1.206 provider gate, because the docs' auto-mode requirements page lists plan/owner/model/provider requirements but does not mention CLAUDE_CODE_SUBPROCESS_ENV_SCRUB at all.
• Docs gap is related to #38559 (env var missing from docs).

Expected behavior

Either of:

1. Decouple env scrubbing from permission-mode forcing (the original request in #51258) — auto mode has its own classifier-based safety layer, so scrubbing subprocess env and permitting auto mode are orthogonal concerns; or
2. At minimum: (a) surface the actual cause in the interactive/Desktop banner (e.g. "auto mode unavailable because CLAUDE_CODE_SUBPROCESS_ENV_SCRUB is set"), (b) document the interaction on the auto-mode requirements page, and (c) apply the check consistently (either also on mid-session switches, or not at startup either).

Why this matters

Users who enable env scrubbing are the security-conscious ones — the same users auto mode's classifier is designed to serve. Coupling the two silently forces them to choose between env hygiene and auto mode without ever telling them the two are connected.