Windows desktop: spawn_task chip primary button 'Fix in this session' contradicts spawn-to-new-session intent

Summary

The session-management spawn_task tool creates a "suggested task" chip whose documented behavior is: "A chip appears for the user; one click spins it off into its own session." On Claude Code for Windows (desktop app), the chip card's primary button instead reads "Fix in this session" (with a dropdown caret), and clicking it executes the suggested task in the current session.

Why this matters

Agents use spawn_task precisely when work must NOT run in the current session — e.g. multi-repo setups where each repository is owned by its own session and cross-repo edits from the wrong session are a policy violation. The current affordance silently does the opposite of the tool's documented intent: the human clicks the obvious button and the work lands in the wrong session's context, with the wrong working directory and the wrong authority.

Steps to reproduce

1. In a session rooted in repo A, have the agent call spawn_task with cwd pointing at repo B and a prompt meant for a fresh session.
2. The chip renders in the UI (also mirrored as a "Suggested task" card).
3. The primary button on the card is "Fix in this session" — not "Start new session".

Expected

Either the primary action opens a new session rooted at the task's cwd (matching the tool description "spins it off into its own session"), or the card's default action and the tool documentation should agree — with "run in a new session" at minimum available and ideally the default when cwd differs from the current session's root.

Environment

• Claude Code for Windows desktop app, current as of 2026-07-18
• Windows 11 (ARM64)
• Observed with the built-in session-management MCP (spawn_task / dismiss_task)

Workaround

Agent withdraws the chip and falls back to: prompt the user to open a new session in the target folder manually, then deliver the task via a cross-session message. Works, but loses the one-click flow the chip was designed for.