fix: sandbox_allow_unsandboxed_exec should default to true on Windows

[chenmingwei23]

Problem

On Windows, enabling Dev Fleet (and other features backed by MCP agent subprocesses) fails with a 500 / "Backend unavailable" error:

{"error": "app 'dev-fleet' has no reachable backend"}

kirocrew doctor shows all three MCP probes failing:

@kirocrew-cron:     FAIL  Sandbox backend unavailable and allow_unsandboxed_exec is not set. Probe detail: not Linux.
@kirocrew-core:     FAIL  Sandbox backend unavailable and allow_unsandboxed_exec is not set. Probe detail: not Linux.
@kirocrew-computer: FAIL  Sandbox backend unavailable and allow_unsandboxed_exec is not set. Probe detail: not Linux.

Root Cause

agent.sandbox_allow_unsandboxed_exec defaults to false in config/loader.py. On Windows there is no OS-level sandbox backend, so the worktree handler and MCP gateway both fail-closed — which means a fresh Windows install has zero functional MCP tooling out of the box, with no actionable error message.

Fix

Auto-detect the platform at config load time and default sandbox_allow_unsandboxed_exec to true when sys.platform == "win32". The fail-closed posture is correct on Linux (where a real sandbox backend exists); on Windows it is an unusable default.

Workaround (for now): manually set agent.sandbox_allow_unsandboxed_exec: true in ~/.kiro/crew/config.json and restart the gateway.

Impact

Every Windows user hitting this for the first time gets a mysterious 500 with no path to resolution. They must manually edit config.json to unblock basic functionality — terrible first-run experience.

[chenmingwei23]

Scope update — the fix in #1527 is no longer "default the flag to true on Windows".

Two blocking reviews rejected that, correctly. dashboard/handlers/worktree.py chooses mode="strict" specifically so a repo-controlled include.path cannot make git read ~/.aws/credentials, and the Papyrus compile path chooses it so a crafted .tex cannot typeset a secret into a PDF. Since detect_backend() is always "none" on win32, a platform default would have unwrapped every one of those spawns with no operator having declared anything.

Also worth recording: the "no actionable error message" half of this issue has already been fixed on main by _PROBE_ERROR_MAX_CHARS = 1200 — the old 200-char cap truncated the remedy sentence mid-word, so a Windows user saw …Probe detail: not Linux. and nothing about the config key. kirocrew doctor now surfaces the full remedy.

What remains — and what the PR now does — is make acting on that remedy a one-step choice instead of a manual config.json edit: kirocrew setup detects a backend-less host, states that ~/.aws and ~/.ssh become readable by agent subprocesses, and prompts (defaulting to no). The key is written only on an explicit yes, so the fail-closed posture the specs document is unchanged.

A follow-up worth filing separately: a first-party carve-out that lets the three managed MCP servers (fixed, KiroCrew-controlled argv) spawn while the agent/repo-controlled callers stay fail-closed. That would make Windows work with no opt-in at all, but it adds an authorization axis to a security-critical function with ~30 call sites, so it needs its own design pass.