Nested claude -p instances hang when CLAUDECODE env var is inherited

Description

When claude -p is launched from within a Claude Code session (e.g., via the Bash tool or a script invoked by Claude Code), the child process inherits environment variables including CLAUDECODE=1 and CLAUDE_CODE_ENTRYPOINT=cli. These cause the nested instance to hang during startup — the process loads (300MB RSS, Node.js event loop running), but never establishes an API connection.

Reproduction

1. Open a Claude Code CLI session
2. From the Bash tool, run: claude -p "Say hello" --dangerously-skip-permissions &
3. After 30 seconds, check the process: ss -tnp | grep $PID shows 0 connections
4. The process sits in epoll_pwait2 indefinitely with 0% CPU

Expected behavior

The nested claude -p instance should connect to the API and complete the prompt, regardless of parent environment.

Actual behavior

~50-60% of workers launched from within Claude Code never connect. They start (PID exists, 300MB allocated) but hang forever with zero network connections and zero MCP server children.

Workaround

Strip the following environment variables before launching nested instances:

• CLAUDECODE
• CLAUDE_CODE_ENTRYPOINT
• CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC

Workers launched from external scripts (clean shell) or with these vars stripped succeed 10/10.

Investigation details

Controlled experiments (15 total) on v2.1.32, WSL2:

• Inline Bash tool launch: ~50% hang rate
• External script launch: 0% hang rate (10/10 pass)
• Clean /tmp dir (no MCP, no hooks, no CLAUDE.md): still hangs inline
• Hung workers: 0 network connections, 0 children, sleeping in epoll_pwait2
• Successful workers: 2+ API connections within 3-10 seconds

Environment

• Claude Code: 2.1.32
• Platform: WSL2, Linux 5.15.167.4
• System: 98GB RAM

Related issues

• #25629 (post-completion hang — separate bug, same investigation)
• #22172 (parallel instance hang with hooks)