Windows: launcher starts bundled claw-server 0.0.7 instead of installed 0.0.11, silently reverting the #1807 structuredContent fix

[kauki42]

Summary

On Windows, the launcher starts the bundled claw-server from Application\<chrome_ver>\BrowserClawServer\default\ (0.0.7) instead of the updated one under User Data\.browseros\BrowserClawServer\versions\<current_version>\ (0.0.11), even though current_version says 0.0.11.

Because 0.0.7 predates #1807, this silently reverts the structuredContent fix: read / snapshot / grep again return only metadata to clients that prefer structuredContent (Claude Code). Nothing errors — tool calls "succeed" and just come back empty-ish, which is exactly the symptom #1560 describes. A user who verified their setup once will silently regress on the next restart.

Environment

• BrowserClaw 0.47.10.0 (BrowserClaw_v0.47.10_x64_installer.exe), Chromium 148.0.7958.97
• Windows 11 x64
• current_version = 0.0.11, versions\0.0.11\ present

What happens

First launch — both servers end up running:

{"msg":"claw-server listening","url":"http://127.0.0.1:9210"}   <- bundled 0.0.7
{"msg":"claw-server listening","url":"http://127.0.0.1:9211"}   <- updated 0.0.11 (9210 was taken)

runtime.json then points at 9211 (the updated one), so a fresh setup works.

Every subsequent launch — only the bundled one comes up:

Port   PID    Path
9210   56896  ...\BrowserClaw\Application\148.0.7958.97\BrowserClawServer\default\resources\bin\browseros-claw-server.exe

$ curl -s -X POST http://127.0.0.1:9210/mcp -d '{"jsonrpc":"2.0","id":1,"method":"initialize",...}'
{"result":{"serverInfo":{"name":"browseros-claw-server","title":"BrowserOS","version":"0.0.7"}}}

runtime.json still says 9211 and is not rewritten on this bind, so external port discovery now points at a server that isn't running.

The regression, side by side

run with return 2+2:

0.0.7 (bundled, what actually runs):

{"content":[{"type":"text","text":"ok\nreturn: 4"}],"structuredContent":{"ok":true,"value":4,"logs":[]}}

0.0.11 (installed, what should run):

{"content":[{"type":"text","text":"ok\nreturn: 4"}]}

Same for read: 0.0.11 returns content-only; 0.0.7 pairs the text with a metadata-only structuredContent ({"page":1,"format":"markdown","contentLength":167}), and Claude Code shows only the latter.

Two things that make recovery harder

1. browseros-claw-server.exe requires --config (--config is required), which isn't obvious when trying to start the versioned binary by hand.
2. It binds ports.server from config.json with no fallback: Failed to start server. Is port 9210 in use?. So the versioned server cannot come up while the bundled one holds the port — which is precisely the steady state after a restart.

Expected

The launcher should start versions\<current_version>\ when it exists, and the bundled default\ only as a fallback. Ideally the bundled server shouldn't linger on ports.server at all once an updated version is installed.

Workaround

Kill whatever holds ports.server, then start the versioned binary explicitly:

Stop-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 9210).OwningProcess -Force
& "$env:LOCALAPPDATA\BrowserClaw\User Data\.browseros\BrowserClawServer\versions\0.0.11\resources\bin\browseros-claw-server.exe" `
    --config "$env:LOCALAPPDATA\BrowserClaw\User Data\.browseros\config.json"

Then initialize reports browserclaw 0.0.11 and read returns full page content again.

Related

Separately, the Windows onboarding import fails ("Something went wrong. BrowserClaw couldn't finish this import.") for every profile and item combination I tried, including a single harmless item, and the dialog is full of macOS copy ("macOS will ask…", "Keychain prompt", footer "Signed build for Mac. v1.0."). Since the import step can't be skipped in this build, the browser stays on chrome://browseros-onboarding/ with no browser window, and every tabs call fails with CDP error: No browser window available. Happy to file that separately if useful.

[kauki42]

Follow-up that narrows this down a lot: the respawn path already resolves the version correctly — only the initial launch doesn't.

Kill the server the app started, touch nothing else, and the supervisor brings one back from versions\<current_version>\, on the same port:

# fresh launch, nothing else running
Server nach Start: PID 54420  Application\148.0.7958.97\BrowserClawServer\default\resources\bin\browseros-claw-server.exe   <- bundled 0.0.7

# kill it, wait, do nothing else
App hat nachgelegt: PID 35368  User Data\.browseros\BrowserClawServer\versions\0.0.11\resources\bin\browseros-claw-server.exe   <- 0.0.11

LocalPort OwningProcess
9210      35368

config.json keeps ports.server: 9210 throughout, and the respawned server is fully healthy (tabs list works, read returns content, no structuredContent).

So the supervisor and the launcher disagree about which binary to use. Whatever resolution the respawn path performs looks like the correct one; the first start seems to skip it and take the bundled default\ copy. Worth noting that config.json already points directories.resources at ...\versions\0.0.11\resources even while the bundled 0.0.7 binary is the one running — so the config is right and only the binary choice is wrong.

That also explains why this is easy to miss: verify right after installing and everything looks fine (the updater has just downloaded the new version and the app is running it), then every launch after that silently drops back to the bundled one.

Workaround, for anyone hitting this

Don't start the versioned server by hand — it needs --config and binds ports.server with no fallback, so a hand-started instance survives the browser and holds the port; the next launch then drifts to 9211/9212 and a static MCP client config points at a dead server answering tabs failed: CDP not connected. I lost a while to exactly that, self-inflicted.

Just kill the app's server and let the supervisor do it:

$port = (Get-Content "$env:LOCALAPPDATA\BrowserClaw\User Data\.browseros\config.json" -Raw | ConvertFrom-Json).ports.server
$owner = Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort $port).OwningProcess
if ($owner.Path -like '*\default\*') { Stop-Process -Id $owner.Id -Force }   # supervisor respawns the versioned one