Deferred tools (Monitor) unavailable in interactive sessions launched from inside a Claude session — env-var stripping does not help, only full environment replacement does

Body

Summary

On Windows (claude-code 2.1.211 / 2.1.212), an interactive claude session started from within another Claude session (via the Bash tool, through any process chain) never receives deferred tools — ToolSearch for Monitor returns no results. Stripping every documented nesting-detection variable does not fix it. The only reliable workarounds are full environment replacement: Start-Process -UseNewEnvironment, or delegating the launch to explorer.exe.

This contradicts the documented behavior that nesting detection relies on the presence of CLAUDECODE / CLAUDE_CODE_CHILD_SESSION (refs: #25803, #32618).

Environment

• Windows 11, claude-code 2.1.211 and 2.1.212 (npm global), pwsh 7.6.3, MSYS2 bash (Git for Windows)
• Also confirmed on macOS 2.1.186/2.1.211 that headless claude -p is NOT affected (deferred tools resolve fine even with all env markers present)

Repro

1. Create t.cmd:

``
@echo off
cd /d C:\path\to\repo
claude
``

1. From an interactive Claude session, via Bash tool:

pwsh -NoProfile -Command "Start-Process cmd -ArgumentList '/c','C:\path\to\t.cmd'"

1. In the new window ask: "Use ToolSearch with query select:Monitor" → NOT FOUND
2. Double-click the same t.cmd in Explorer → FOUND

What we ruled out

• Env stripping is not sufficient. A variant of t.cmd that clears CLAUDECODE, CLAUDE_CODE_CHILD_SESSION, CLAUDE_CODE_ENTRYPOINT, CLAUDE_CODE_SESSION_ID, CLAUDE_CODE_EXECPATH, CLAUDE_EFFORT, AI_AGENT (plus GIT_EDITOR, COREPACK_ENABLE_AUTO_PIN, NoDefaultCurrentDirectoryInExePath, WSLENV, WT_SESSION, WT_PROFILE_ID in a second round) before running claude still yields NOT FOUND when launched from the Claude-descendant chain.
• Project .claude/settings.json contents (allow lists, hooks, env blocks) — full matrix tested, no effect.
• Landing directory — same directory works via double-click, fails via descendant launch.
• Version alone — same binary works via double-click.

What works

• Start-Process ... -UseNewEnvironment from the descendant chain → FOUND
• explorer.exe C:\path\to\t.cmd from the descendant chain → FOUND

Both replace the child environment wholesale rather than selectively, which suggests an additional, undocumented environment marker (or another env-carried channel) participates in nesting detection in 2.1.21x.

Questions

1. Is there an additional env marker (beyond CLAUDECODE / CLAUDE_CODE_CHILD_SESSION) that gates deferred-tool registration in interactive sessions?
2. Is "deferred tools disabled for nested interactive sessions" intended behavior? If so, is there a supported opt-out for orchestrator-style workflows that intentionally spawn independent top-level sessions?