Summary

• Problem: gateway.controlUi.allowedOrigins can include a custom desktop-app origin like tauri://localhost, but the gateway normalises that browser Origin header to the opaque null origin and never matches the explicit allowlist entry.
• Why it matters: Tauri/Electron-style Control UI wrappers have to fall back to wildcard origins even when operators want a specific origin allowlist.
• What changed: preserve the exact scheme://host origin for non-special URL schemes when the browser sends a scheme and host, then continue matching through the existing lower-case allowlist path.
• What did NOT change (scope boundary): literal Origin: null remains rejected, unlisted custom origins remain rejected, and host-header/local-loopback fallbacks keep their existing rules.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: Origin validation fails for custom URL schemes (tauri://, electron://) #46520
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: new URL("tauri://localhost").origin returns the opaque string null, so exact allowlist matching compares tauri://localhost with null.
• Missing detection / guardrail: the origin-check unit table did not include custom-scheme browser origins.
• Contributing context (if known): browser desktop wrappers can send non-special scheme origins even though those schemes do not have a standard web origin serialisation.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/gateway/origin-check.test.ts
• Scenario the test should lock in: allowlisted custom-scheme origins match exactly after normalisation, while unlisted custom-scheme origins still fail.
• Why this is the smallest reliable guardrail: the bug is isolated to origin normalisation before the existing allowlist check.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

Operators can set gateway.controlUi.allowedOrigins to values like tauri://localhost without using * for desktop Control UI wrappers.

Diagram (if applicable)

Before:
tauri://localhost -> URL.origin "null" -> allowlist miss

After:
tauri://localhost -> preserved custom origin -> explicit allowlist match

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A. This keeps explicit allowlist matching required for non-wildcard custom-scheme origins.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local source checkout
• Model/provider: N/A
• Integration/channel (if any): Gateway Control UI origin check
• Relevant config (redacted): gateway.controlUi.allowedOrigins = ["tauri://localhost"]

Steps

1. Configure gateway.controlUi.allowedOrigins with tauri://localhost.
2. Connect with browser Origin: tauri://localhost.
3. Compare against checkBrowserOrigin behaviour.

Expected

• The explicit custom-scheme allowlist entry is accepted.
• Unlisted custom-scheme origins are rejected.

Actual

• Current main sees new URL("tauri://localhost").origin as null, so the explicit allowlist entry does not match.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Local command evidence:

• git diff --check HEAD~1..HEAD passed.
• Manual Node parser check passed for tauri://LOCALHOST, electron://localhost, https://CONTROL.example.com, literal null, and malformed not a url cases.
• pnpm docs:list was attempted but blocked by Corepack registry timeout while downloading pnpm 10.33.0 (UND_ERR_CONNECT_TIMEOUT).
• pnpm test src/gateway/origin-check.test.ts reached the repo test wrapper via cached pnpm but could not run because this worktree has no vitest dependency and dependency installation is blocked by registry timeouts.

Human Verification (required)

• Verified scenarios: source-level root cause in Node URL behaviour; exact custom-scheme origin preservation; literal null and malformed origins still return no parsed origin.
• Edge cases checked: upper-case custom origin host normalises to lower case; unlisted custom scheme remains rejected by the unit table.
• What you did not verify: local Vitest/full changed gate, because this machine cannot install missing npm dependencies from the registry. CI should run the new test.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: custom desktop wrapper origins could be over-accepted.
  • Mitigation: this only changes the parsed origin string; explicit allowlist, wildcard, host-header fallback, and local-loopback checks remain the same, and tests cover an unlisted custom-scheme rejection.