[Yicheng-Mark]

Symptom

POST /api/hermes/update — or the Desktop app's "Update backend" affordance against a remote Windows backend — fails with HTTP 500:

{"detail": "Failed to start update: [WinError 5] Access is denied."}

whenever the dashboard/gateway runs inside a Windows job object that does not grant JOB_OBJECT_LIMIT_BREAKAWAY_OK (Task Scheduler, certain service runners, sandboxed sessions). No update ever starts. As reported in #135179.

Cause

_spawn_hermes_action in hermes_cli/web_server_gateway.py spawned the action with windows_detach_flags() unconditionally, and those flags include CREATE_BREAKAWAY_FROM_JOB. In a job that forbids breakaway, Popen raises PermissionError (WinError 5), which the endpoint surfaced as the 500.

_subprocess_compat.windows_detach_flags documents the exact contract: "A job that forbids breakaway yields PermissionError from Popen — callers catch OSError and fall back to windows_detach_flags_without_breakaway." gateway.py, gateway_windows.py and main_desktop.py follow it; this spawn site was the one that didn't.

Fix

Catch OSError from the breakaway spawn and retry once with windows_detach_flags_without_breakaway(), mirroring gateway.py's respawn path. The POSIX branch (start_new_session) is unchanged.

Regression tests added:

• a denied breakaway (PermissionError on the breakaway flags) retries with the without-breakaway flags and still records the action's process handle;
• a permitted breakaway spawns exactly once, with the breakaway flags;
• POSIX keeps start_new_session and passes no creationflags.

Fixes #135179

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds a functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass — ran the new test module against the patched file on Windows (3/3), stubbing only the module's collaborators; full suite runs in CI
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Windows 11

Documentation & Housekeeping

• I've updated relevant documentation — N/A, spawn behavior only
• I've updated cli-config.yaml.example — N/A
• I've updated CONTRIBUTING.md or AGENTS.md — N/A
• I've considered cross-platform impact — both platform branches covered by tests
• I've updated tool descriptions/schemas — N/A

[alt-glitch]

This was generated by AI during triage.

This overlaps #129325 and #108720. #129325 is the narrower canonical dashboard repair; this PR retries all OSErrors, so it has a material behavioral delta and is related rather than a duplicate.

[Yicheng-Mark]

Closing in favor of #129325 (by @ggmmlong, opened 9 days earlier), which fixes the same spawn site in hermes_cli/web_server_gateway.py.

Comparing the two diffs, theirs is also the better fix: it gates the fallback on winerror == 5, so unrelated spawn failures (missing exe, bad cwd) keep surfacing as a single clear error, while this PR retried on every OSError. Its tests also exercise the real windows_detach_flags() values rather than sentinel constants. Nothing here is left uncovered by #129325.

#135179 stays reproducible until that lands — the terminal hermes update workaround from #129325 applies meanwhile.