Let the AI features go out through a corporate proxy

[Sev7eNup]

Why

In a network where outbound traffic is only allowed through a proxy, the AI features cannot reach a cloud endpoint at all: the LLM HttpClient hard-codes UseProxy = false, and no configuration key exists to change that. Every call runs into its timeout and surfaces as "LLM endpoint did not respond within {TimeoutSeconds}s", including the Settings "Test connection" button, which shares the same named client.

The fix was written on 2026-08-06 and pushed to claude/llm-endpoint-test-context-wsl22m, but no pull request was ever opened, so it stayed outside main while the symptom kept being reported. This lands it on current main.

What

A global Llm:Proxy block covering every outbound LLM call — both chats, script and workflow generation, the llmQuery activity, and the settings probe.

Key	Default	Meaning
Mode	Off	Off = direct, System = the proxy the service account's OS is configured with (incl. its own bypass rules), Custom = the address below
Address	""	Proxy URL; required for Custom
BypassList	[]	Shell globs reached directly; Custom only
Username / Password	null	Basic auth; password encrypted at rest, plaintext raises a startup hardening warning
UseDefaultCredentials	false	NTLM/Kerberos with the service account

One block per installation rather than one per profile: the mixed case — cloud model through the proxy, local Ollama direct — is what the bypass list is for, and a single block keeps one handler with one connection pool.

The proxy deliberately does not live in the SocketsHttpHandler. That handler is built once per handler lifetime, so binding the config there would have made the whole Llm settings section restart-required, the way RestApi is. Instead LlmConfiguredProxy implements IWebProxy and resolves IOptionsMonitor per request, which keeps the section hot-reloadable. In Off mode it bypasses every destination, making "no proxy configured" byte-for-byte the direct connection this client made before.

Security trade-off, documented at the type and in the reference: with a proxy in the path the proxy resolves destination DNS, so the connect-time link-local guard only covers the proxy endpoint. The destination stays protected by the literal BaseUrl check that runs on every save and at boot. No mandatory allow-list as restApi has — the LLM BaseUrl is a single Admin-only value, not a per-step URL assembled from trigger payloads.

Proxy rules are validated in LlmProfileValidation, which both AddNodePilotAi and LlmConfigBootValidator run, so a save that is accepted cannot block the next boot. The bypass-glob translation moves to NodePilot.Core.Net.ProxyBypassPattern so the Engine and Ai stacks share it instead of drifting apart.

Landing notes

Only one merge conflict: the IntegrationsSection imports, where main had since added refreshAiCapabilities next to the SectionFormHelpers import the proxy form needs. Both are kept.

One E2E test needed a fix that is not part of the original commit. 38.3 located the LLM Test button with a page-wide .last(). The LLM card renders its heading while the section snapshot is still loading, so that could resolve to SMTP's Test button before the profile form mounts — the test then drove the SMTP probe and timed out. It was already a race on main; the extra proxy form widened it enough to fail a full-file run. The lookup is now scoped to the LLM card.

Verification

• dotnet build clean; full backend suite green — 5404 tests across six projects.
• Frontend: tsc --noEmit clean, 2540 vitest tests green, eslint at 0 errors / 13 warnings (the lint:ci cap).
• Playwright: full suite green, 379 passed / 22 skipped. admin-settings verified against main first to confirm the failure was introduced here and not pre-existing.
• Regression that matters: Mode: Off still connects directly, covered by LlmConfiguredProxyTests.