Interactive session gets API 401 after MCP tools load via ToolSearch when USER env var is set (v2.1.201)

Environment

• Claude Code v2.1.201 (native install), macOS 15 (Darwin 25.5.0), arm64
• Reproduces with BOTH subscription keychain auth and a claude setup-token CLAUDE_CODE_OAUTH_TOKEN

Symptom

In an interactive session, the first API request AFTER MCP tools are loaded via ToolSearch fails with:

⏺ Please run /login · API Error: 401 Invalid authentication credentials

The session transcript records "error":"authentication_failed", "apiErrorStatus":401 with a real requestId, on a <synthetic> assistant message. Requests BEFORE the MCP tools load succeed (the model answers, calls ToolSearch, gets results) — only the next request after MCP tool schemas are loaded fails.

Trigger: the USER environment variable

Bisected from a tmux server environment by starting from env -i and adding variables back in groups:

# WORKS - loads and calls the MCP tool fine
env -i HOME="$HOME" PATH="$PATH" TERM=xterm CLAUDE_CODE_OAUTH_TOKEN="$TOK" \
  claude --permission-mode auto "Use ToolSearch to load the mcp__<server>__<tool> tool, then call it."

# FAILS with 401 right after the MCP tools load - only difference is USER
env -i HOME="$HOME" PATH="$PATH" TERM=xterm CLAUDE_CODE_OAUTH_TOKEN="$TOK" USER="$(whoami)" \
  claude --permission-mode auto "Use ToolSearch to load the mcp__<server>__<tool> tool, then call it."

Deterministic across ~17 runs (7 failing, 10 passing, perfectly correlated with USER). LOGNAME does NOT trigger it; USER alone does.

Matrix

| mode | USER set | MCP tools loaded via ToolSearch | result |
|---|---|---|---|
| interactive | no | yes | OK |
| interactive | yes | no | OK |
| interactive | yes | yes | 401 |
| -p (print) | either | yes | OK |

• Both stdio (chrome-devtools-mcp) and HTTP MCP servers trigger it — the MCP server itself is irrelevant (the HTTP server answers 200 to direct probes; the stdio server needs no auth at all).
• /status in a failing session shows Auth token: CLAUDE_CODE_OAUTH_TOKEN, and the same token works fine in the no-USER case, so it is not credential validity.

🤖 Filed with Claude Code after an env-bisection session.