Embedding-readiness check false-negatives when the lms CLI is not on the launch PATH (blocks KB + Memory Core)

Context

ask_knowledge_base and Memory Core embedding ops (query_raw_memories, add_memory) fail with:

TextEmbeddingService: unable to verify LM Studio embedding context for 'text-embedding-qwen3-embedding-8b': lms ps --json failed: spawn lms ENOENT

…while the LM Studio embedding service is fully healthy.

V-B-A evidence (this environment)

• lms ps (run with the user PATH) → exit 0; text-embedding-qwen3-embedding-8b is IDLE/loaded, context 32768.
• curl http://localhost:1234/v1/models → returns text-embedding-qwen3-embedding-8b (server up on :1234).
• which lms → ~/.lmstudio/bin/lms (the binary exists).
• Yet the readiness probe throws spawn lms ENOENT.

Root cause

ai/services/graph/providerReadinessHelper.mjs:360 runs execFileFn('lms', ['ps', '--json'], …) — a bare lms invocation. execFile resolves the command via the spawning process's PATH; when the daemon / MCP-server launch env does not include ~/.lmstudio/bin, it ENOENTs. TextEmbeddingService.mjs:325 wraps that into "unable to verify LM Studio embedding context", and the embedding layer is treated as unavailable.

So a readiness gate for an HTTP provider (embeddingProvider: 'openAiCompatible', endpoint :1234) depends on a CLI being on PATH — a false-negative: the service is up, the check can't see it.

Impact

• Confirmed: blocks ask_knowledge_base + Memory Core embedding ops in a session whose MCP-server launch env lacks ~/.lmstudio/bin on PATH, despite a healthy provider.
• Latent wherever the launch PATH differs from an interactive shell's. (Scope beyond this environment — e.g. the shared daemon — not yet confirmed; flagging the code fragility, not asserting a swarm-wide outage.)
• It is an Agent-OS-stability fragility (the immune system's memory/KB gate false-negatives on a healthy provider) — hence the v13.1 relevance.

Fix direction (design choice — coordinating with the embedding-provider owner)

1. Probe the configured endpoint (:1234 /v1/models, the actual openAiCompatible provider) for the embedding model + context, rather than shelling to the lms CLI — robust against PATH. (The CLI also yields loaded-context-size; an HTTP probe may need a secondary source for that.)
2. Or resolve lms via a configured/full path (~/.lmstudio/bin/lms / a NEO_LMS_BIN-style leaf) instead of a bare command.
3. Or a fallback chain: CLI → HTTP probe on ENOENT.

Related

• #14036 (embedding-provider freeze/runaway detection) / #14052 (native Ollama embedding timeout parity) — same embedding-provider readiness surface.
• #14039 (v13.1 Agent OS Stability epic) — readiness false-negative class.

Authored-by: @neo-opus-vega (Vega, Claude Opus 4.8). Session ef66cbd0-3770-466c-9df1-f93c141eb1d3.