Add configurable custom CLI launcher support

[PureWeen]

Summary

• add a Custom CLI source with a user-specified executable path and optional launcher arguments
• use the configured launcher for embedded sessions, persistent server startup, login commands, and model probing
• add regression coverage for settings serialization, launch argument construction, and provider mapping

Validation

• dotnet test PolyPilot.Tests/PolyPilot.Tests.csproj --filter "FullyQualifiedNameCliPathResolutionTests|FullyQualifiedNameConnectionSettingsTests|FullyQualifiedNameSettingsRegistryTests|FullyQualifiedNameServerManagerTests|FullyQualifiedNameProviderPluginTests|FullyQualifiedNameProtocolVersionMismatchTests|FullyQualifiedName~ServerRecoveryTests" --nologo
• dotnet build PolyPilot.slnx -c Debug --nologo

[PureWeen]

PR Review

CI status: ⚠️ No GitHub checks are currently reported on this branch. The PR description includes local dotnet test + dotnet build validation, but there isn't a branch CI signal to rely on yet.

Existing review feedback: No prior review comments were present, so nothing is duplicated here.

🟡 MODERATE

1. Backslashes in custom launcher arguments are being stripped
   File: PolyPilot/Models/ConnectionSettings.cs (around SplitCommandLineArguments, lines 317-379)
   Consensus: All 3 reviewers agree after adversarial follow-up.

   SplitCommandLineArguments() currently treats every \ as an escape character outside single quotes:

   if (ch == '\\' && quote != '\'')
   {
       escaping = true;
       continue;
   }

   That silently corrupts path-bearing custom arguments such as:

   • --config C:\Users\me\.copilot\config.json
   • --config "C:\Program Files\Git\bin\bash.exe"

   by dropping the backslashes before the arguments ever reach ProcessStartInfo.ArgumentList. The result is a mangled path like C:Usersme.copilotconfig.json, which makes the new custom-launcher feature fail in exactly the scenario where users are most likely to need it.

   Why it matters: this PR introduces a user-facing “custom launcher” flow, and path arguments are a common use case. The failure is silent and will be hard for users to diagnose.

   Requested fix: preserve literal backslashes (or adopt platform-correct parsing rules) and add regression tests for unquoted and double-quoted Windows/UNC path cases.

🟢 MINOR

1. Test coverage gap on the new parser path
   The new code paths are otherwise covered well, but the added tests only exercise quotes/spaces. They do not cover backslash-heavy inputs, which is why the bug above slipped through. Please extend the test matrix when fixing the parser.

No other actionable issues survived consensus.

Recommendation: ⚠️ Request changes — please fix the backslash/path parsing issue and add the missing regression tests before merge.

[PureWeen]

PR Review (re-review)

CI status: ⚠️ No GitHub checks are currently reported on this branch. Local validation in the PR plus the follow-up fix includes targeted parser regression tests and a full solution build.

Previous findings status

1. Backslashes in custom launcher arguments were being stripped
   Status: ⚠️ PARTIALLY FIXED
   The common path/UNC cases are now handled correctly, and the added regression tests cover the original issue well.

2. Test coverage gap on the new parser path
   Status: ⚠️ PARTIALLY FIXED
   Coverage was improved substantially, but one important edge case is still missing.

🟡 MODERATE

1. Double-quoted paths ending in a trailing backslash still swallow subsequent arguments
   File: PolyPilot/Models/ConnectionSettings.cs (SplitCommandLineArguments)
   Consensus: All 3 reviewers agree.

   The updated parser still misparses inputs like:

   --workdir "C:\MyProject\" --next-flag
   

   Because the backslash immediately before the closing " is treated as escaping the quote, the quote never closes and everything after it gets folded into the same token. In practice that means --next-flag is silently swallowed instead of being passed as its own argument.

   Why it matters: a trailing \ on a quoted directory path is a normal Windows form. This still leaves a real silent-corruption case in the new custom-launcher feature.

   Requested fix: handle the trailing-backslash-before-closing-quote case correctly and add a regression test for a quoted path ending in \.

Current assessment

The earlier bug is mostly fixed, but this edge case still needs to be addressed before merge.

Recommendation: ⚠️ Request changes — please fix the trailing-backslash quoted-path case and extend the tests for it.

[PureWeen]

/review

[github-actions]

✅ Expert Code Review completed successfully!

[github-actions]

Design-Level Findings (outside diff hunks)

These findings involve removed defensive code — the issues are about what is now missing, not specific new lines.

---

🔴 CRITICAL — Sibling reconnect failure leaves IsProcessing stuck forever (Flagged by: 3/3 reviewers)

File: PolyPilot/Services/CopilotService.cs — sibling reconnect catch block

ClearProcessingState(capturedOtherState) was removed from the sibling reconnect error handler. If ForceCompleteProcessingAsync fails (catch swallows) and ResumeSessionAsync also fails, IsProcessing remains true on an orphaned state. The watchdog explicitly exits for orphaned states (if (state.IsOrphaned) return;), so the session shows "Thinking…" indefinitely.

Recommendation: Restore ClearProcessingState(capturedOtherState) + NotifyStateChangedCoalesced() in the sibling catch block.

---

🟡 MODERATE — Sibling reconnect drops FlushedResponse (Flagged by: 3/3 reviewers)

File: PolyPilot/Services/CopilotService.cs — sibling reconnect state creation

Primary reconnect preserves FlushedResponse but the sibling path no longer carries it forward. Accumulated response text from prior tool rounds is silently discarded.

Recommendation: Restore FlushedResponse carry-forward in the sibling reconnect path.

---

🟡 MODERATE — ClearPendingOrchestrationAndResetState removal drops ReflectionState cleanup (Flagged by: 2/3 reviewers)

File: PolyPilot/Services/CopilotService.Organization.cs — 6 call sites

Replaced by bare ClearPendingOrchestration() + OnOrchestratorPhaseChanged. The old method also reset ReflectionState.IsActive = false. Without this, cancelled orchestrations leave ReflectionState.IsActive = true, blocking new reflection cycles permanently.

Recommendation: Add ReflectionState cleanup at each affected call site.

---

🟡 MODERATE — Custom launcher ignored in terminal launch flows (Flagged by: 3/3 reviewers)

File: PolyPilot/Components/Layout/SessionListItem.razor:679, SessionSidebar.razor:3916 (outside diff hunks)

Both call ResolveCopilotCliPath(settings.CliSource) without passing settings.CustomCliPath. For CliSource.Custom, this returns null, silently breaking "Open in Copilot Console" and "Fix with Copilot".

Recommendation: Pass settings.CustomCliPath in both call sites.

---

🟡 MODERATE — RecoveredFromSessionId phantom entries (Flagged by: 3/3 reviewers)

File: PolyPilot/Services/CopilotService.cs + CopilotService.Persistence.cs

RecoveredFromSessionId and _closedSessionIds updates were removed from reconnect fallback paths. MergeSessionEntries() still gates drops on this field. Old sessions now survive merges as phantom "(previous)" duplicates.

Recommendation: Restore these markers in create-fresh fallback paths, or update MergeSessionEntries.

---

🟡 MODERATE — Removed events.jsonl staleness check in watchdog (Flagged by: 2/3 reviewers)

File: PolyPilot/Services/CopilotService.Events.cs + CopilotService.Persistence.cs

The events.jsonl mtime check that upgraded effective watchdog timeout from 120s to 600s when CLI was still writing was removed. Sessions may get prematurely terminated. Also, poll staleness detection (PollMaxStaleCycles) was removed from PollEventsAndResumeWhenIdleAsync.

Recommendation: Restore the events.jsonl freshness-based timeout upgrade.

Warning

⚠️ Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• 192.0.2.1

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "192.0.2.1"

See Network Configuration for more information.

Generated by Expert Code Review for issue #579 · ◷