feat(agent): opt-in interactive-session launch for visible GUI/browser tests

[EliorMachlev]

What

Adds an opt-in Agent:LaunchInInteractiveSession setting that launches the whole agent in the active console session (Session 1) instead of the service's non-interactive Session 0 — so GUI processes it spawns downstream (e.g. a Selenium/NUnit browser) are visible on the logged-in desktop.

"Agent": {
  "LaunchInInteractiveSession": {
    "Enabled": false,        // master switch — off by default
    "LocalSystemOnly": true  // gate the launch on LocalSystem; default on
  }
}

Why it's gated the way it is

This is a deliberate, opt-in isolation downgrade. A Windows service always runs in Session 0; crossing into the interactive session needs WTSQueryUserToken → SeTcbPrivilege, i.e. the service must run as LocalSystem (or an account granted a LocalSystem-equivalent privilege), plus a user logged into the console.

• LocalSystemOnly: true (default) → attempt only when the service is LocalSystem.
• LocalSystemOnly: false → also attempt under a non-LocalSystem account granted SeTcbPrivilege (discouraged — that privilege is LocalSystem-equivalent, so it hides risk rather than reducing it).

Every precondition failure (wrong identity, no console session, missing privilege) logs a prominent warning and falls back to a normal Session 0 (headless) launch — the service never fails because of this setting. Because the shipped default identity (NT SERVICE\Jenkins) lacks the privilege, the feature is effectively double opt-in: flipping the flag alone does nothing until the service identity is also reconfigured.

How

• New InteractiveSessionLauncher does the CreateProcessAsUser launch with stdout/stderr pipe redirection (preserving SEVERE counting + secret redaction) and places the agent tree in a kill-on-close Job Object so stop/restart still reaps the browser/build children. Hardening:SanitizeEnvironment still applies.
• AgentProcessLauncher dispatches to the interop only when enabled; the default (disabled) path is unchanged.
• Startup warning in the worker when the flag is on.

Docs / policy

• docs/configuration.html: settings rows, JSON sample, and an Interactive-session launch section with a top security warning and a prerequisites table for both LocalSystem and non-LocalSystem modes.
• Security.md: reports stemming from enabling this feature are marked out of scope (a defect where it acts without being enabled, or fails to fall back safely, remains in scope).

Testing

• dotnet test -c Release -p:RestoreLockedMode=true → 178/178 pass; config-binding test extended to cover the new nested keys + defaults.
• ⚠️ The interop is compile-verified only. The CreateProcessAsUser path is not exercisable in CI (no interactive session / privilege), same class as the TPM code path — it needs manual validation on a box with autologon + the service set to LocalSystem.

🤖 Generated with Claude Code