fix(cookbook): treat local Windows as Windows for serve commands

[zoomdbz]

Summary

Local Cookbook server entries can have a blank platform. On native Windows that made the local selection look non-Windows, while an earlier browser-side fallback could incorrectly mark a non-Windows Odysseus host as Windows when accessed from a Windows browser.

This PR keeps the scope to the local-Windows serve path:

• source the local host platform from the backend (hostPlatform) instead of navigator.platform / navigator.userAgent;
• include hostPlatform even for fresh or unreadable Cookbook state, and strip it before state is persisted;
• keep local server entries unknown when the backend does not confirm native Windows;
• prefer native llama-server for local Windows llama.cpp serving, using the same Git Bash command shape as local non-Windows serves;
• keep remote Windows on the existing PowerShell/Python-server command shape;
• allow saved absolute llama-server.exe commands through the serve-command validator;
• prepend local Windows serve runners with $HOME/bin and common llama.cpp build output directories so detached Git Bash launches can find a user wrapper or CUDA build of llama-server;
• generate vision --mmproj paths from the scanned GGUF projector file list instead of emitting a runtime $(find ...) command substitution that the backend validator rejects as unsafe;
• warn and block llama.cpp vision launches when Vision is checked but the generated command has no --mmproj / --clip_model_path, so the checkbox cannot silently become a text-only launch;
• fix the helper tests so Windows subprocess-based Bash checks pass the snippet directly instead of escaping $ as if PowerShell were still in the call path.

This prevents local Windows from falling into the Linux/macOS llama.cpp bootstrap path that can build a default Visual Studio Debug binary, avoids the Python server --type_k q4_0 argument failure on the local Windows path, and stops the UI from generating vision commands that either fail with Invalid characters in cmd or silently omit the projector.

Target branch

• This PR targets dev, not main.

Linked Issue

Related to #2636

Type of Change

• Bug fix (non-breaking - fixes a confirmed issue)

Checklist

• I searched open issues and open PRs - this is not a duplicate.
• This PR targets dev
• My changes are limited to the scope described above - no unrelated refactors or whitespace changes mixed in.
• I ran focused tests for the changed behavior.

How to Test

Focused tests:

G:\AI\odysseus\venv\Scripts\python.exe -m pytest tests\test_cookbook_cpu_only_serve.py tests\test_cookbook_helpers.py -q

Result: 73 passed, 1 warning.

Syntax checks:

G:\AI\odysseus\venv\Scripts\python.exe -m py_compile routes\cookbook_routes.py routes\cookbook_helpers.py
node --check static\js\cookbookServe.js

Both passed.

Native Windows smoke check:

export PATH="/g/AI/odysseus/venv/Scripts:$PATH"
command -v llama-server
llama-server --list-devices

Confirmed Git Bash resolves llama-server and llama-server --list-devices reports CUDA0: NVIDIA GeForce RTX 3090 Ti.

Visual / UI changes

Adds a small inline warning in the Serve panel when llama.cpp Vision is enabled but no scanned mmproj projector is available. No layout restructuring.

[alteixeira20]

Thanks for the work here. The current CI is green and the Windows-local platform detection part looks directionally useful, but I cannot approve this PR in its current shape because the diff is broader than the title/scope.

The PR title says:

fix(cookbook): treat local Windows as Windows for serve commands

but the diff also includes several additional behavior changes, including:

• llama-cpp-python cache type normalization
• local detached PID script changes
• Windows process-tree stop behavior
• adding transformers to the package/dependency allowlist
• Linux llama.cpp bootstrap changes such as mkdir -p ~/bin

Those may be valid fixes, but they are separate behavioral changes from local Windows platform detection and make the PR hard to review safely as one unit.

Please either split this into smaller PRs, or retitle/re-scope the PR body so it explicitly covers the broader cookbook/Windows serve stabilization work and includes validation notes for each behavior path changed.

At minimum, I would expect this PR to separate the local Windows platform-detection fix from the unrelated dependency/package and llama.cpp normalization changes.

[zoomdbz]

I split the broad Windows/Cookbook changes out of this PR per review. This PR now only contains the local-Windows platform/serve-path fix:

• local Cookbook entries fall back to the browser Windows platform when the saved platform is blank;
• local Windows llama-cpp-python serves skip the Linux/macOS native llama-server bootstrap;
• the dependency/package, cache normalization, process cleanup, and ~/bin bootstrap changes moved to separate PRs.

Split PRs:

• fix(cookbook): stop local Windows process trees #4073 local Windows process-tree cleanup
• fix(cookbook): create bin dir before llama-server link #4074 llama.cpp ~/bin bootstrap
• fix(cookbook): allow local Windows Diffusers serving #4077 local Windows Diffusers/image dependencies
• fix(cookbook): normalize llama-cpp-python cache types #4078 backend llama-cpp-python cache type normalization

Focused local test for this PR: 3 passed.

[RaresKeY]

Thanks for splitting the broader Windows/Cookbook work. I took a pass over the current narrowed diff as the remaining local-Windows platform/serve-path fix and found one issue.

Findings

issue (cookbook): Do not use the browser OS as the local server OS

• Problem: This uses navigator.platform / navigator.userAgent to fill the platform for the local server entry when the backend did not provide one. But local here means the Odysseus host process, not the browser device. If someone opens a Linux/macOS/Docker Odysseus instance from a Windows browser, the frontend records the local server as platform: "windows" and _getPlatform("local") returns that.

• Impact: Local download/serve requests from that browser send req.platform == "windows" even though the command will run on a non-Windows host. The backend then skips the non-Windows tmux availability preflight because is_windows is true, while local_windows = IS_WINDOWS and not remote is still false. That leaves the request in the local non-Windows execution path with a Windows-shaped command.

• Ask: Please source the local server platform from the backend/host environment, or only apply this Windows fallback when the backend confirms the Odysseus host is native Windows. If the host platform is unknown, preserve unknown instead of inferring it from the browser. A regression for a Windows browser talking to a non-Windows local server would cover this.

• Location: static/js/cookbook.js:117

Validation

• Ran:

  • node --check static/js/cookbook.js
  • python -m pytest tests/test_cookbook_cpu_only_serve.py tests/test_cookbook_helpers.py::test_local_windows_llama_cpp_skips_native_bash_build -q

• Not run:

  • Browser E2E with a Windows client against a non-Windows Odysseus host.
  • Native Windows serve flow.

[zoomdbz]

Addressed the requested local-platform issue in the narrowed PR:

• removed the navigator.platform / navigator.userAgent local OS fallback from static/js/cookbook.js;
• added a backend-sourced hostPlatform field for client state, currently only set to windows when the Odysseus host process is native Windows;
• local server entries now use that host state or remain unknown, so a Windows browser connected to a Linux/macOS/container host will not mark the local server as Windows;
• hostPlatform is stripped before state is posted back for persistence, so it stays a live backend fact instead of saved user config.

Validation run locally:

python -m pytest tests/test_cookbook_cpu_only_serve.py -q
node --check static/js/cookbook.js
node --check static/js/cookbookRunning.js

Result: 2 passed; both JS syntax checks passed.

[zoomdbz]

Updated this PR after native Windows validation.

Changes since the previous review response:

• kept the backend-sourced hostPlatform approach, so local platform is not inferred from the browser;
• added the local Windows llama.cpp path to prefer native llama-server instead of python -m llama_cpp.server;
• kept remote Windows on the existing PowerShell/Python-server command shape;
• allowed saved absolute llama-server.exe commands through validation;
• added source-level regression coverage for backend host platform and local Windows native server selection.

Focused validation:

G:\AI\odysseus\venv\Scripts\python.exe -m pytest tests\test_cookbook_cpu_only_serve.py tests\test_cookbook_helpers.py::test_local_windows_llama_cpp_skips_native_bash_build -q

Result: 4 passed.

Also ran node --check static\js\cookbook.js and node --check static\js\cookbookRunning.js; both passed.

[alteixeira20]

Thanks for the update and the native Windows validation. The PR is now much better scoped, the split-out work is no longer mixed into this diff, and the mechanical validation looks good: clean merge probe, green checks, focused pytest passed, and both Cookbook JS syntax checks passed.

I still see one local-platform edge case before I can approve this.

The backend-sourced hostPlatform direction is right, but _localHostPlatform() still falls back to _envState.platform when hostPlatform is empty:

return _envState.hostPlatform || (!_envState.remoteHost ? _envState.platform : '') || '';

For a non-Windows Odysseus host, the backend intentionally returns an empty hostPlatform. If _envState.platform contains a stale/persisted "windows" value from older client state, the local server can still be treated as Windows even though the host is not Windows.

Could you make the local host platform resolution depend only on the backend-sourced hostPlatform for the local entry, so unknown remains unknown, and add/adjust the regression test to cover stale _envState.platform = "windows" with empty hostPlatform?

[RaresKeY]

One more local Windows serve-path edge case, separate from the hostPlatform fallback issue already called out above.

Findings

issue: Local Windows llama-server commands miss the local-Windows guard

• Problem: The frontend emits llama-server --model ... for the native local-Windows serve path, but the backend guard that avoids the Git Bash/source-build flow only checks local_windows and "llama_cpp" in req.cmd. A generated llama-server command can therefore fall through to the generic llama-server bootstrap branch.

• Impact: Local Windows users can still be routed into the native source-build/bootstrap path this PR is intended to avoid.

• Ask: Include llama-server in the local-Windows skip/guard path, or align the emitted command with the existing guard. Please add a regression that feeds the generated local-Windows serve command through the backend helper and asserts it does not enter the source-build bootstrap branch.

• Location: routes/cookbook_routes.py:1379

Validation

Focused Cookbook serve/helper tests passed, and both changed JavaScript files parse with node --check.

[zoomdbz]

Addressed the two latest local-Windows review points and rebased this PR onto the current origin/dev.

Changes in the refreshed branch:

• local platform resolution now uses backend-sourced hostPlatform for the local entry only; stale/persisted _envState.platform = "windows" no longer marks an unknown/non-Windows local host as Windows;
• generated native local-Windows llama-server --model ... commands are included in the backend local-Windows skip guard, so they do not enter the Linux/macOS source-build bootstrap path;
• regression coverage now checks both the stale local-platform fallback and the local-Windows llama-server bootstrap skip.

Focused validation run locally:

G:\AI\odysseus\venv\Scripts\python.exe -m pytest tests\test_cookbook_cpu_only_serve.py -q

Result: 7 passed.

Syntax checks:

G:\AI\odysseus\venv\Scripts\python.exe -m py_compile routes\cookbook_routes.py routes\cookbook_helpers.py
C:\Users\Dominic\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe --check static\js\cookbook.js
C:\Users\Dominic\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe --check static\js\cookbookRunning.js

Result: passed.

[zoomdbz]

Follow-up on the current red Python tests (pytest) check: the failure is unrelated to this Cookbook/Windows diff.

The failing tests are all README/docs refresh regressions:

• tests/test_docs_no_orphan_images.py::test_no_orphan_images_in_docs
• tests/test_readme_ascii_fenced.py::test_readme_banner_is_inside_a_code_fence
• tests/test_readme_ascii_fenced.py::test_readme_title_stays_a_heading
• tests/test_security_regressions.py::test_readme_native_quickstart_uses_loopback

This PR does not touch README.md or docs/. The focused Cookbook tests and syntax/security/static checks for this branch pass; the README test follow-up appears to be tracked separately in #4311.

[alteixeira20]

Thanks for the follow-up. The new hostPlatform direction and the backend llama-server guard are improvements, and the focused validation is green, but I still cannot approve because the stale local-platform case is not fully closed.

_getPlatform('local') now uses only hostPlatform, but local serve payload paths can still use stale _envState.platform:

1. static/js/cookbook.js:_renderRecipes writes the local server entry platform from _envState.hostPlatform || _envState.platform || ''.
2. static/js/cookbookServe.js:_selectedServeTarget returns server?.platform || _envState.platform || '' for local.
3. static/js/cookbookRunning.js:_launchServeTask uses _envState.platform when _host is local and sends it as platform.

That means a non-Windows Odysseus host with stale persisted _envState.platform = "windows" can still send req.platform == "windows" for a local serve, which preserves the edge case from my previous review.

Please make all local platform payload resolution depend only on backend-sourced hostPlatform, avoid writing stale _envState.platform onto the local server entry, and add a regression for local serve payload construction with empty hostPlatform plus stale _envState.platform = "windows".

[zoomdbz]

Addressed the requested stale local-platform follow-up and rebased onto current origin/dev.

Changes:

• local server entries now set platform from backend-sourced hostPlatform only, never stale _envState.platform;
• _selectedServeTarget now returns hostPlatform for local targets and server.platform only for remote targets;
• _launchServeTask now sends hostPlatform for local serve payloads, so a stale persisted _envState.platform = "windows" cannot mark a non-Windows local host as Windows;
• added regression coverage for the local serve payload/stale platform case.

Validation:

• G:\AI\odysseus\venv\Scripts\python.exe -m pytest tests\test_cookbook_cpu_only_serve.py tests\test_cookbook_helpers.py -q -> 76 passed, 1 warning
• G:\AI\odysseus\venv\Scripts\python.exe -m py_compile routes\cookbook_routes.py routes\cookbook_helpers.py -> passed
• node --check static\js\cookbook.js, node --check static\js\cookbookServe.js, node --check static\js\cookbookRunning.js -> passed

[zoomdbz]

Rebased this PR again onto the latest origin/dev (now including upstream through 93569b1) and force-pushed the refreshed branch. No conflicts during rebase. Local validation after the rebase:

• \G:\AI\odysseus\venv\Scripts\python.exe -m pytest tests\test_cookbook_cpu_only_serve.py tests\test_cookbook_helpers.py -q\ -> \76 passed, 1 warning\
• \G:\AI\odysseus\venv\Scripts\python.exe -m py_compile routes\cookbook_routes.py routes\cookbook_helpers.py\ -> passed
• 
  ode --check static\js\cookbook.js, \static\js\cookbookServe.js, \static\js\cookbookRunning.js\ -> passed
• \git diff --check origin/dev..HEAD\ -> passed

[zoomdbz]

Rebased this PR onto the latest origin/dev after it had fallen 17 commits behind the base branch, then force-pushed the refreshed branch.

Current head: 6770cad

Local validation after the rebase:

• G:\AI\odysseus\venv\Scripts\python.exe -m pytest tests\test_cookbook_cpu_only_serve.py tests\test_cookbook_helpers.py -q -> 76 passed, 1 warning
• G:\AI\odysseus\venv\Scripts\python.exe -m py_compile routes\cookbook_routes.py routes\cookbook_helpers.py -> passed

ode --check static\js\cookbook.js, static\js\cookbookServe.js, static\js\cookbookRunning.js -> passed

• git diff --check origin/dev..HEAD -> passed

GitHub checks on the refreshed branch are green as well.

[zoomdbz]

Rebased this PR onto current origin/dev (91b4171). The branch is now 0 behind / 2 ahead of dev.

This update keeps the local Windows llama-server behavior while folding in the newer upstream Cookbook serve changes. It also addresses the stale local platform review path by keeping local serve payload/platform resolution on backend-sourced hostPlatform instead of persisted _envState.platform.

Validation:

• Local: python -m pytest tests/test_cookbook_cpu_only_serve.py tests/test_cookbook_helpers.py -q -> 79 passed
• Local: node --check for static/js/cookbook.js, static/js/cookbookServe.js, static/js/cookbookRunning.js
• Local: Python compile checks for touched routes/tests
• Local: git diff --check origin/dev..HEAD
• GitHub checks after push are green

Remaining useful follow-up is still a live Windows/Git Bash + GPU llama-server smoke test on an actual local Windows host.

[zoomdbz]

Follow-up fix pushed for a UI regression in the serve launch panel.

The issue was a conflict-resolution newline flattening in static/js/cookbookServe.js: the first hwfit-serve-row opener was accidentally left on the same line as a comment, so the generated launch panel DOM lost that row wrapper. I also split panel._cmd = cmd back onto its own executable line.

Added a regression assertion in tests/test_cookbook_cpu_only_serve.py to catch this exact flattened-line case.

Validation:

• Local focused tests: 80 passed
• Local JS syntax checks: cookbook.js, cookbookServe.js, cookbookRunning.js
• GitHub checks on this PR head are green

[zoomdbz]

Follow-up pushed after another pass over the serve code. I found one selected-target edge case: command preview/building still derived local-vs-remote from global _envState.remoteHost, while launch used _selectedServeTarget(panel). That could build a local Windows serve command as a remote/PowerShell-style command if a remote server was configured but the user picked Local in the Serve panel.\n\nThis update syncs updateCmd() to _selectedServeTarget(panel), writes the selected host back into the hidden host field, and makes _buildServeCmd() use f.host when present. It also updates the CUDA hwfit host comparison to use the selected target host.\n\nLocal validation:\n- python -m pytest --noconftest tests/test_cookbook_cpu_only_serve.py tests/test_cookbook_helpers.py -q -> 81 passed\n- node --check static/js/cookbook.js -> passed\n- node --check static/js/cookbookServe.js -> passed\n- git diff --check -> passed

[zoomdbz]

Rebased this PR onto current dev (6a2a39f). The branch is now 0 behind / 3 ahead of dev. Local validation after the rebase: python -m pytest --noconftest tests\test_cookbook_cpu_only_serve.py tests\test_cookbook_helpers.py -q -> 81 passed, 2 warnings; node --check for static/js/cookbook.js, static/js/cookbookServe.js, static/js/cookbookRunning.js -> passed; git diff --check origin/dev..HEAD -> passed. GitHub checks on the refreshed branch are green. Remaining blocker is the stale requested-changes review state.

[zoomdbz]

Rebased this PR onto current dev (5d23495) after it drifted behind again. The branch is now 0 behind / 3 ahead of dev. Current head: 40ec988. Local validation after the rebase: python -m pytest --noconftest tests\test_cookbook_cpu_only_serve.py tests\test_cookbook_helpers.py -q -> 81 passed, 2 warnings; node --check for static/js/cookbook.js, static/js/cookbookServe.js, static/js/cookbookRunning.js -> passed; git diff --check origin/dev..HEAD -> passed. GitHub checks on the refreshed branch are green. Remaining blocker is still the stale requested-changes review state.

[zoomdbz]

Rebased this PR onto current dev (de12d47) and force-pushed with lease after explicit approval. The branch is now 0 behind / 3 ahead of dev. Current head: f67b12f. Local validation before push: python -m pytest --noconftest tests\test_cookbook_cpu_only_serve.py tests\test_cookbook_helpers.py -q -> 81 passed, 2 warnings; node --check for static/js/cookbook.js, static/js/cookbookServe.js, static/js/cookbookRunning.js -> passed; git diff --check origin/dev..HEAD -> passed. GitHub checks on the refreshed branch are green. Remaining blocker is still the stale requested-changes review state.

[zoomdbz]

@alteixeira20 quick blocker-specific follow-up: the current head addresses the stale local-platform review path you called out. Local server entries and local serve payloads now use backend-sourced hostPlatform only, not stale _envState.platform; remote server platform handling remains separate; and regression coverage checks the empty hostPlatform plus stale _envState.platform = "windows" case. The branch is current with dev, mergeable, and GitHub checks are green. Could you please re-review when you have a chance and either clear/update the stale requested-changes state or leave any remaining concrete blocker?

[alteixeira20]

LGFM.

I re-reviewed the current head after the follow-up fixes and rebases.

Validation:

• PR head verified: f67b12fb
• clean merge probe against current dev
• GitHub checks are green
• focused Cookbook tests and syntax checks are covered
• scope is now limited to the local-Windows Cookbook serve/platform path and focused regression coverage

My previous blocker was that local serve payload paths could still use stale _envState.platform = "windows" when hostPlatform was empty. The current head addresses that:

• local server entries now use backend-sourced hostPlatform
• local serve target selection uses hostPlatform for local targets and server.platform only for remote targets
• local serve launch payloads use hostPlatform instead of stale _envState.platform
• regression coverage checks the stale local-platform case
• the local Windows llama-server command path is guarded so it does not fall into the Linux/macOS bootstrap path

The remaining native Windows/Git Bash + live GPU llama-server smoke test is useful follow-up, but I do not see it as a blocker for this scoped fix.