The netstat-based parser matched the literal English "LISTENING"
state string, which is translated on non-English Windows (e.g.
"ABHÖREN", "ÉCOUTE", "ESCUTANDO"). On those systems the regex matched
zero lines, so killProcessOnPort silently did nothing -- fail-open,
not a regression, but ineffective for the exact users the fix targets.
Replace it with `Get-NetTCPConnection -State Listen -LocalPort <port>`,
which reads the same underlying WinNT API netstat's display layer
translates, so it's unaffected by OS display language. Verified
against a real listening port on this machine (matched the actual
owning PID).
Also fixed a stale duplicate of the "killProcessOnPort is a no-op on
Windows" comment left behind in server/index.js.
killProcessOnPort() was a no-op on win32 (POSIX-only, via lsof/kill),
so a restart could leave the old OpenCode process holding the port
while a new instance spawned on a different one. That's a plausible
contributor to a chronic pattern seen in production logs: repeated
"OpenCode process exited, restarting" cycles and hundreds of
ECONNRESET/proxy errors over multiple days on Windows.
Give killProcessOnPort a real Windows branch: parse `netstat -ano`
for PIDs listening on the target port, filter out our own pid, and
force-kill each via `taskkill /PID <pid> /F` (no /T -- we don't own
that process, so only the listener itself is killed, not any
children it may have).
waitForPortRelease()'s existing soft-fail-and-warn behavior is left
untouched -- it's a deliberate safety net for any platform where the
port doesn't free up in time, not just Windows, and the restart
already rebinds event-stream readers to the actual resulting port via
onOpenCodeRestarted.
PR #2520fixed#2475 in the wrong layer (overflow classes on
SettingsView.tsx wrapper divs that aren't the actual scroll containers),
so the "no scrollbar in Settings" bug shipped in v1.17.2 unchanged, and
the sessions feed has the same underlying issue (#2402).
The actual scroll containers render through ScrollableOverlay ->
OverlayScrollbar, which hides the native scrollbar and draws its own
JS thumb that auto-hides ~1s after scroll activity stops, with a
second CSS rule fully hiding that thumb inside Settings specifically.
Fix both at the shared component/CSS layer so every consumer (Settings,
sessions feed, git panels, chat, etc.) gets a persistent scrollbar on
desktop shells (Electron + VS Code webview) in one change:
- OverlayScrollbar.tsx: skip the auto-hide timer and show the thumb
immediately on mount when content overflows, on desktop runtimes.
userIntentOnly consumers (chat auto-follow scroll, reasoning blocks)
keep today's intent-gated behavior unchanged.
- index.css: scope the Settings-specific hide rule to non-desktop, so
mobile/web keep existing behavior and desktop gets the thumb back.
Replace overflow-hidden with overflow-y-scroll on 5 content wrapper divs
so Settings sub-panels (Shortcuts, Plugins, etc.) have an always-visible
vertical scrollbar on both desktop and mobile.
Fixes#2475
Sérgio Pedro