claude-code - 💡(How to fix) Fix 2.1.144/145: CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 in settings.json + --chrome freezes input for ~3.5 min at startup (macOS)

Summary

When CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 is set in ~/.claude/settings.json's env: block, it silently overrides --dangerously-skip-permissions AND combines with the --chrome flag to freeze the input box for ~3.5 minutes at session startup on macOS. The TUI renders, but keystrokes are buffered and not displayed until the freeze ends — at which point everything typed appears at once.

Started reproducing on 2026-05-19 immediately after upgrading from 2.1.143 → 2.1.144, and persists on 2.1.145.

Reproducer

1. macOS 26.4.1 (arm64).

2. ~/.claude/settings.json includes in its env block:

   "env": {
     "CLAUDE_CODE_SUBPROCESS_ENV_SCRUB": "1"
   }

3. No Chrome MCP bridge present (/tmp/claude-mcp-browser-bridge-<user>/ does not exist).

4. Launch:

   claude --chrome --dangerously-skip-permissions --add-dir ~/Pavisus ~/hub

5. TUI renders within ~2-3s. Input box is visible but does not accept keystrokes for ~3.5 minutes.

6. After ~3.5 min, every keystroke buffered during the freeze appears at once. A status-bar message is visible the whole time:

   Permission mode forced to default — CLAUDE_CODE_SUBPROCESS_ENV_SCRUB is set (allowed_non_write_users hardening). Declare allowedTools explicitly, or set CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=0 to opt out.

Expected

Either:

• The status-bar message appears immediately (it does) AND the input box is responsive immediately (it is not), with permission enforcement happening asynchronously / in parallel with input handling, OR
• If permission enforcement must complete before input is accepted, the TUI should show a spinner / progress indicator on the input box so the user knows it's waiting, not hung.

Actual

Input box appears idle/responsive (cursor blinks) but swallows keystrokes silently for ~3.5 minutes. There is no spinner, no progress bar, no log line on stderr indicating that startup is still in progress. From the user's perspective, the session looks dead.

Diagnosis

Three factors stack:

1. CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 triggers allowed_non_write_users hardening, which forces the session back to default permission mode regardless of --dangerously-skip-permissions. To run anything without prompts, CC then walks allowedTools on every configured MCP server. (~7 MCP servers configured here, but .claude.json has dozens of empty allowedTools: [] entries for legacy per-project scopes.)
2. --chrome tries to discover or initialize a Chrome MCP bridge socket. When the bridge isn't present, there appears to be a retry loop with a multi-minute timeout.
3. Under serialized permission gating (1), the Chrome bridge discovery (2) blocks input handling instead of running concurrently.

Settings.json env injection has higher precedence than shell env, so a claude() wrapper function in ~/.zshrc that prefixes CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=0 command claude "$@" is silently defeated. That's expected behavior, but it makes the hardening flag harder to debug because env | grep in the parent shell shows =0 while the spawned CC process gets =1 from settings.json.

Workarounds (any one of these fixes it)

• Remove CLAUDE_CODE_SUBPROCESS_ENV_SCRUB from ~/.claude/settings.json's env: block (relying on shell env or default).
• Drop --chrome from the launch command (Chrome MCP can be enabled per-session via claudeInChromeDefaultEnabled or on-demand).
• Add --permission-mode bypassPermissions explicitly.

Environment

• Claude Code: 2.1.145 (also reproduces on 2.1.144; did not reproduce on 2.1.143)
• macOS: 26.4.1 (Darwin 25.4.0, arm64 / Apple Silicon)
• Shell: zsh
• MCP servers configured: 7 (google-workspace, mailbox, nextcloud, caldav, claude-peers, safari-browser, tavily) + claude-in-chrome (not auto-enabled — claudeInChromeDefaultEnabled: false)

Suggested fix

Either:

• Decouple Chrome MCP bridge discovery from input-handling readiness (run async at startup so input is accepted while bridge discovery happens / times out in background), OR
• Reduce Chrome bridge discovery timeout from ~3.5 min to ~15s with a visible warning, OR
• Document that CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 in settings.json env is incompatible with --chrome and surface a startup warning the moment the flag combination is detected.

Related: #50167 (SUBPROCESS_ENV_SCRUB silently overrides sandbox.enabled — confirms this variable has undocumented side-effects).