fix(web-ui): serve /ui on Windows by comparing against the platform separator

[saucam]

Fixes #299.

The bug

The path-traversal guard in src/frontends/web-ui/index.ts tested containment with a hardcoded /:

if (target !== DIST && !target.startsWith(`${DIST}/`))

normalize() emits the platform separator, so on Windows every legitimate asset resolves to C:\...\web\dist\index.html — which does not start with C:\...\web\dist/. The guard fired on valid files and the whole UI returned 403 Forbidden.

What the guard was actually doing

Worth recording, because it changes how you read this diff: that 403 branch is unreachable over HTTP. The WHATWG URL parser resolves .. segments (and folds \ to / for http) before handleFetch ever sees the path:

http://h/ui/../../../etc/passwd  ->  pathname "/etc/passwd"
http://h/ui/..\..\x              ->  pathname "/x"

Both fall out of the /ui/ prefix check entirely. So the guard's only observable effect in production was this Windows false positive. It is still correct defense-in-depth, so this fixes it rather than dropping it.

The fix

The reporter's one-line sep fix is right, but no test on a POSIX CI machine can verify it. So the mapping moves into a pure resolveUiAsset(distRoot, urlPath, pathFlavor) — the precedent buildBootScript already set in this module. The path flavor is injectable, so path.win32 reproduces the Windows behaviour from Linux and the regression is covered where CI actually runs. handleFetch drops to three lines.

Tests

src/tests/web-ui-asset-path.test.ts, 14 cases across both flavors: legitimate nested assets, the mount root with and without a trailing slash, SPA deep links, .. traversal, and a sibling directory that merely shares the root's string prefix (web/dist-secrets).

Confirmed to catch the regression — reverting the guard to ${distRoot}/ fails four win32 cases; restoring ${distRoot}${p.sep} passes.

Verification

Full suite 2443 pass / 0 fail; typecheck and biome clean.

End to end against a live local-mode daemon (bun src/cli.ts start --local):

Request	Result
/ui, /ui/	200 text/html
/ui/assets/index-*.js	200 text/javascript, 498706b
/ui/assets/index-*.css	200 text/css, 52480b
/ui/sessions/abc (SPA deep link)	200 text/html
/ui/assets/nope.js	404
4 traversal payloads, incl. %2f-encoded	never escaped dist

Then the real UI path: harvested the injected __CODEOID_LOCAL_TOKEN__ from the served HTML, opened the WebSocket, auth.ok, session.list.result → 4 sessions.

Not verified on Windows hardware — I have no Windows host here. The win32 coverage is path.win32 semantics, which is precisely where the bug lived; @yl-dev-tmtc confirmed the equivalent sep fix resolves it on a real Windows machine.

Thanks to @yl-dev-tmtc for reporting this with the cause and the fix already identified.

🤖 Generated with Claude Code