Aegis v0.2.9 (macOS): LLM gateway crashes on startup (import_meta.url undefined), plus external-endpoint/VLM bugs #215

Environment: SharpAI-Aegis v0.2.9 (Electron 40.2.1), macOS (Darwin 25.5.0). LLM and VLM both set to "OpenAI Compatible" pointing at a local Ollama (http://127.0.0.1:11434/v1, VLM qwen2.5vl:7b, LLM gemma4:e4b).

The LLM settings screen says "Connected", but the agent chat fails and clip analysis never works. I traced it through the app and found five separate problems (details and line numbers are from the unpacked app.asar).

1. LLM gateway crashes at startup, so port 5407 never opens (main blocker)

Startup log:

[TRACE] LLM Gateway failed to start: The argument 'filename' must be a file URL object, file URL string, or absolute path string. Received undefined
[LLM IPC] Gateway reload failed (may not be running): request to http://localhost:5407/api/config/reload failed

dist_electron_main/gateway.cjs ~line 2017: var import_meta = {}; followed by createRequire(import_meta.url). In the CJS bundle import_meta.url is undefined, so loading throws. Every agent/LLM call then fails with fetch failed.
Also: line ~2083 does esmRequire("../../../electron/config/cloud-providers.cjs"), and that file is not in the packaged build, so chat requests fail with Cannot find module once the first crash is patched.

2. LLM settings screen doesn't switch the active engine

Selecting "OpenAI Compatible" only writes ~/.aegis-ai/llm-config.json. ~/.aegis-ai/config/active-inference.json stayed on {"engineId": "llama-cpp", "port": 5411} and config/agent_config.json stayed on "llm": {"mode": "builtin"}, so the app still thinks the built-in server is the LLM.

3. VLM health checks ignore the external endpoint

• video_analyze (and the background trigger inside video_search) probe http://localhost:<vlm_server port 5405>/health even when vlm.mode === "external". Nothing listens there, so the agent says "VLM unavailable" although the external VLM works.
• The VLM monitor requests <externalEndpoint>/health, which Ollama answers with 404 (it has no /health), so the VLM can look offline. /v1/models would be a more portable check.

4. video_analyze / background analysis pass a null thumbnail

main.cjs ~30553: deepAnalyze(clipId, null, camera || "unknown", 0), and ~30396: bgAnalyze(clip.id, null, ...). analyzeClip then runs fs.existsSync(thumbnailPath) on null and returns Thumbnail not found: null, so these tool paths never reach the VLM. (The motion-event paths pass a real thumbnailPath and look fine.) After this the chat model tells the user the VLM is unavailable, which is misleading.

5. Thinking models return empty replies

With Gemma (thinking) models via Ollama, requests use max_tokens ~512, the model spends it on reasoning, and the reply has an empty content (reasoning is in a separate reasoning field):

[Agent] SSE stream ended with finish_reason=length — response was truncated (hit max_tokens limit)
[Agent] LLM response - has tool_calls: false, content length: 0

The user sees "I'm still warming up — try asking again in a moment." Sending reasoning_effort: "none" for local endpoints made replies reliable here (usable replies went from 2/4 to 5/5 in my test); raising the token limit or reading the reasoning field would also help.

Workarounds used

Ran a patched copy of the gateway outside the app (fix for #1 plus reasoning_effort: "none" for #5) and a tiny stub answering GET /health on 5405 (for #3).

Happy to test fixes.