Sibling LLM-init bypasses + embed-client wire-shape gap left open by #1142

[alphaonedev]

Severity: HIGH (post-#1142 QC found four sibling sites + one wire-shape mismatch)

Status: FIXED in commit 8d51118 on release/v0.7.0. This issue is filed retroactively to provide the audit-trail for the fix per the prime directive (every defect surfaces a tracker entry).

Background

#1142 ported the AI_MEMORY_LLM_BACKEND env-aware resolver from src/daemon_runtime.rs:1746-1798 into the MCP stdio LLM-init at src/mcp/mod.rs:2148-2208. The narrow MCP-LLM symptom was fixed.

A QC pass against the binary at commit f5151201b (using codegraph_callers over OllamaClient::{new, new_with_url, from_env} + rg for production non-test sites) found four sibling code paths that still bypassed the env-aware resolver, plus one wire-shape mismatch in the MCP embed-client fallback:

Defects

1. src/cli/commands/atomise.rs::build_llm_curator — hardcoded OllamaClient::new(&tier_default_model). ai-memory atomise locked to local Ollama regardless of operator env.
2. src/cli/curator.rs::build_curator_llm — same hardcode. The ai-memory curator CLI (sweep / reflect / daemon modes) could not reach xAI / OpenAI / Anthropic / Gemini / etc.
3. src/daemon_runtime.rs::run_curator_daemon_with_primitives — legacy primitive-args entrypoint built the LLM directly from the ollama_model: Option<String> arg, ignoring AI_MEMORY_LLM_BACKEND.
4. src/mcp/mod.rs embed-client fallback — when embed_url == ollama_url (the default) and AI_MEMORY_LLM_BACKEND set to a non-Ollama vendor, the embed client did llm.clone(). That cloned an OpenAI-compatible chat client and used it for /api/embed requests, which either don't exist (xAI, Anthropic) or hit a different model namespace. Semantic recall silently fell back to keyword-only with no operator-visible warning.

Drive-by: src/handlers/kg.rs:593 was missing use crate::models::Memory at HEAD f5151201b, breaking cargo build --release. Fixed in the same commit per the prime directive (every gap surfaces a fix).

Resolution

Commit 8d511185f:

• New OllamaClient::build_for_init(legacy_url, legacy_model) -> Result<Option<Self>> in src/llm.rs centralises the env-aware-then-legacy resolution rule. Behaviour mirrors daemon_runtime::build_llm_client's async wrapper.
• New OllamaClient::is_ollama_native() -> bool introspector so embed-client fallback paths can refuse to clone an OpenAI-compatible chat client for embedding requests.
• All four bypass sites refactored to route through the env-aware path.
• MCP embed-client fallback rebuilds a dedicated Ollama-wire-shape client at the configured embed URL when the LLM is non-Ollama.

Tests

Six new regression tests in src/llm.rs::wiremock_tests::*_1143:

• is_ollama_native_true_for_ollama_client_1143
• is_ollama_native_false_for_openai_compatible_1143
• build_for_init_legacy_arm_when_env_unset_1143
• build_for_init_env_arm_routes_to_from_env_1143
• build_for_init_env_arm_unknown_alias_errors_1143
• build_for_init_env_arm_empty_string_falls_back_to_legacy_1143

All six pass. Full suite AI_MEMORY_NO_CONFIG=1 cargo test --release --lib: 4681/4681 GREEN.

Smoke evidence

$ AI_MEMORY_LLM_BACKEND=xai AI_MEMORY_LLM_API_KEY=$XAI_API_KEY \
  AI_MEMORY_LLM_MODEL=grok-4.3 ai-memory mcp --tier autonomous --profile full
ai-memory: requested tier = autonomous
ai-memory: profile = 8 families (...); expected tool count = 73
ai-memory: LLM ready (backend=xai, model=grok-4.3)
ai-memory: LLM client is OpenAI-compatible (non-Ollama wire shape);
           building dedicated Ollama embed client at http://localhost:11434 (#1143)
ai-memory: embedder loaded (nomic-embed-text-v1.5 (768-dim, Ollama))
ai-memory: atomisation engine ready (curator=LlmCurator)
ai-memory MCP server started (stdio, tier=autonomous)

The new (#1143) banner line confirms the wire-shape disambiguation is taking effect.

Gates

• cargo fmt --check: GREEN
• cargo clippy --release --lib -- -D warnings -D clippy::all -D clippy::pedantic: GREEN
• AI_MEMORY_NO_CONFIG=1 cargo test --release --lib: GREEN (4681 passed, 0 failed)

Verified per prime directive pm-v3 (memory cd8ede94).

[alphaonedev]

Fixed via commit 8d51118. Retest evidence:

• cargo fmt --check GREEN
• cargo clippy --release --lib -- -D warnings -D clippy::all -D clippy::pedantic GREEN
• AI_MEMORY_NO_CONFIG=1 cargo test --release --lib GREEN — 4681/4681 passed, including the 6 new wiremock_tests::*_1143 regression tests
• MCP stdio smoke with AI_MEMORY_LLM_BACKEND=xai confirms the new banner line LLM client is OpenAI-compatible (non-Ollama wire shape); building dedicated Ollama embed client at http://localhost:11434 (#1143) is emitted, proving the embed-client wire-shape disambiguation is reached at runtime.

Binary at /Users/fate/v07/v07-fixes/.cargo-shared-target/release/ai-memory rebuilt at 19:56 (post-fix). strings confirms both is_ollama_native and the new banner are present.

Verified per prime directive pm-v3 (memory cd8ede94).

[alphaonedev]

Reopening: fifth sibling site missed — boot-banner LLM field bypasses the env-aware resolver

Triage context (2026-05-22, operator-directed reopen). A live ai-memory boot --quiet invocation against a release/v0.7.0-mobile-ci-1068 binary built at HEAD 8d511185f (the closing commit for this issue) reports:

tier:       autonomous (embedder=nomic-ai/nomic-embed-text-v1.5, reranker=ms-marco-MiniLM-L-6-v2, llm=gemma4:e4b)

The llm=gemma4:e4b field is unaffected by the env-aware resolver this issue introduced, and would continue to misreport even when an operator has set AI_MEMORY_LLM_BACKEND=xai AI_MEMORY_LLM_MODEL=grok-4.3 (or any non-Ollama backend). Per the prime directive that pinned the original four sibling sites, this is a fifth bypass site and belongs in the same campaign.

Root cause

src/cli/boot.rs:392-394 reports the LLM field by reading the compiled tier preset, not the env-aware resolver:

let llm = tier_config
    .llm_model
    .map_or_else(|| "none".to_string(), |m| m.ollama_model_id().to_string());

tier_config.llm_model here is the static tier preset defined in src/config.rs:165-178:

Self::Smart => TierConfig {
    ...
    llm_model: Some(LlmModel::Gemma4E2B),
    ...
},
Self::Autonomous => TierConfig {
    ...
    llm_model: Some(LlmModel::Gemma4E4B),
    ...
},

So:

• The field reports compiled tier defaults regardless of operator env.
• It does NOT consult AI_MEMORY_LLM_BACKEND / AI_MEMORY_LLM_MODEL / AI_MEMORY_LLM_BASE_URL.
• It does NOT consult the llm_model field operators set in ~/.config/ai-memory/config.toml.
• It does NOT call OllamaClient::build_for_init (the env-aware resolver this issue centralised in src/llm.rs).

The in-file comment at src/cli/boot.rs:384-386 documents the pre-#1143 design intent:

// Resolve the *configured* tier. Boot doesn't materialize the
// embedder / LLM / reranker handles, so these reflect what would
// load — not what actually loaded.

Post-#1143 that contract is wrong for operators: the boot banner is the load-bearing operator-visible signal for "what LLM is wired up right now" (it's emitted by the SessionStart hook on every Claude Code session boot), and silently misreporting it defeats the purpose of the env-aware resolver work.

Proposed fix

1. Add a sync, side-effect-free helper alongside OllamaClient::build_for_init that returns the resolved (backend, model) pair without instantiating a client. Roughly:

   // src/llm.rs
   pub fn resolve_backend_and_model_for_boot(legacy_model: Option<&str>)
       -> (BackendKind, String)

   Mirrors build_for_init's env-precedence rule (ladder: AI_MEMORY_LLM_BACKEND env > legacy tier_config.llm_model > "none") but never opens sockets, never reads AI_MEMORY_LLM_API_KEY. ~25 LOC.

2. Replace the lookup at src/cli/boot.rs:392-394 with a call to the new helper. Surface as llm=<backend>:<model> (e.g. llm=xai:grok-4.3, llm=ollama:gemma4:e4b) so the operator can distinguish backend+model in one glance. ~5 LOC change + signature plumbing through BootManifest::new.

3. Two regression tests in src/cli/boot.rs::tests:

   • boot_manifest_llm_field_honors_env_backend_1143_sibling5
   • boot_manifest_llm_field_falls_back_to_tier_preset_when_env_unset_1143_sibling5

4. Smoke evidence: re-run AI_MEMORY_LLM_BACKEND=xai AI_MEMORY_LLM_MODEL=grok-4.3 ai-memory boot --quiet and assert the banner reports llm=xai:grok-4.3.

Why this belongs here and not as a separate issue

Operator directive 2026-05-22: keep the campaign for #1142 → #1143 audit-trail unified. The bypass mechanism is identical (compiled / hardcoded fallback shadows the env-aware path); only the surface differs (informational banner vs. live LLM client). Closing #1143 on the four LLM-init sites alone left a fifth surface emitting drifted output, which is the same class of defect.

Gates expected on the fix commit

• cargo fmt --check: GREEN
• cargo clippy --release --lib -- -D warnings -D clippy::all -D clippy::pedantic: GREEN
• AI_MEMORY_NO_CONFIG=1 cargo test --release --lib: GREEN (4683 expected after +2 new tests)
• Live smoke against the rebuilt binary showing llm=xai:grok-4.3 when env is set, llm=ollama:gemma4:e4b when unset.

Filed per prime directive pm-v3 (memory cd8ede94). Verified pre-reopen against the live binary at /Users/fate/v07/v07-fixes/.cargo-shared-target/release/ai-memory (mtime 2026-05-22 19:56, HEAD 8d511185f).

[alphaonedev]

Scope expansion (operator-directed, 2026-05-22)

Live debugging surfaced a second dimension to sibling-site #5: even with the proposed boot.rs fix (route through the env-aware resolver), the banner will continue to misreport because the SessionStart hook process that spawns ai-memory boot --quiet ... does not inherit the MCP server's env block.

Two-process picture confirmed

Process	Launched by	Inherits ~/.claude.json mcpServers.memory.env?
MCP server (ai-memory mcp --tier autonomous)	Claude Code from mcpServers.memory config	yes
Boot-banner emitter (ai-memory boot --quiet --limit 10 --budget-tokens 4096)	Claude Code's SessionStart hook runner	no

Verified on this host: ~/.claude/settings.json::hooks.SessionStart[].hooks[] carries no env field; the hook command runs in the hook-runner's own environment, which does not surface the MCP-server-scoped env block.

Consequence: a boot.rs-only fix solves only half the problem. With AI_MEMORY_LLM_BACKEND absent from the hook process env, the env-aware resolver's legacy arm still wins and the banner still reports the compiled tier preset (gemma4:e4b).

Expanded fix surface

1. src/cli/boot.rs:392-394 — route through the env-aware resolver (as originally proposed). Continue to support process-env override as the highest-precedence source. ~5 LOC.

2. src/llm.rs — new sync helper resolve_backend_and_model_for_boot — as originally proposed. ~25 LOC.

3. NEW: ai-memory boot reads ~/.claude.json (and other MCP-client config files) as a fallback source for the env block. Discovery rule:

   • On any platform, look for $HOME/.claude.json (Claude Code config canonical path).
   • Within that file, traverse mcpServers.<name>.env for any <name> whose command resolves (via which / direct check) to the same binary that's running ai-memory boot right now (i.e. the binary that called into boot.rs).
   • The matched env block becomes a lower-precedence source than process env but higher than the compiled tier preset.
   • Skip silently if ~/.claude.json doesn't exist or doesn't parse cleanly (no error, no warning — this is a best-effort enhancement).
   • Add a one-line debug-tracing emit (tracing::debug!) on the resolved source so RUST_LOG=ai_memory=debug ai-memory boot shows which path won.

   This keeps the operator from having to maintain duplicate env declarations in settings.json and claude.json. ~80 LOC including a tiny inline JSON-path helper (serde_json is already in the dependency tree).

4. Regression tests in src/cli/boot.rs::tests:

   • boot_manifest_llm_field_honors_process_env_1143_sibling5 — env wins
   • boot_manifest_llm_field_falls_back_to_claude_json_1143_sibling5 — temp dir + temp claude.json fixture
   • boot_manifest_llm_field_falls_back_to_tier_preset_1143_sibling5 — neither env nor claude.json matches
   • boot_manifest_llm_field_skips_unmatched_claude_json_entries_1143_sibling5 — claude.json with mismatched binary path is ignored

5. Future design note (not in scope for this PR): the cleanest long-term endpoint is a [llm] table in ~/.config/ai-memory/config.toml (backend, model, base_url, api_key_file). The current config.toml llm_model = "gemma4:e4b" field is post-feat(llm): provider-agnostic LLM substrate — every tier, every vendor, every deployment posture (supersedes #1066) #1067 incomplete — it only covers the Ollama-native legacy arm, not the env-aware resolver's full configuration surface. The ~/.claude.json read above is a pragmatic short-term measure (covers the most common multi-NHI host topology) while the longer-term [llm] section design is decided. Filed for a follow-up issue.

Gates expected on the expanded fix commit

• cargo fmt --check: GREEN
• cargo clippy --release --lib -- -D warnings -D clippy::all -D clippy::pedantic: GREEN
• AI_MEMORY_NO_CONFIG=1 cargo test --release --lib: GREEN (4685 expected after +4 new tests)
• Live smoke: ai-memory boot --quiet (no env, no flags) reads ~/.claude.json and reports llm=xai:grok-4.3 matching the configured MCP server.

Operator workaround until the fix lands

Inline the env on the SessionStart hook command in ~/.claude/settings.json:

"command": "AI_MEMORY_LLM_BACKEND=xai AI_MEMORY_LLM_MODEL=grok-4.3 ai-memory boot --quiet --limit 10 --budget-tokens 4096"

Note ai-memory boot makes no network calls, so the API key is not needed in the hook env — only backend + model.

Verified per prime directive pm-v3 (memory cd8ede94). Operator-directed scope expansion confirmed in live session 2026-05-22.

[alphaonedev]

Subsumed by #1146

Closing as the scope of #1143 ("sibling-site cleanup") is structurally too narrow for the actual gap the live-debugging session surfaced: the ai-memory configuration surface is fragmented across five disjoint sources (config.toml, ~/.claude.json env block, settings.json hook env, compiled tier presets, process env) and no resolver consults a single source of truth.

The fix is not "close the fifth sibling site" — it's "introduce the [llm] / [embeddings] / [reranker] / [storage] config sections, route every surface through one canonical resolver, eliminate the ~/.claude.json env-block duplication, and forbid inline API keys." That work is tracked under #1146 with full schema spec, migration plan, secret-handling discipline, doctor reachability check, and acceptance criteria.

#1143's four LLM-init site fixes (atomise / curator / daemon-primitives / MCP embed-client wire-shape) remain landed in 8d511185f on release/v0.7.0-mobile-ci-1068; the boot-banner sibling-5 gap is now folded into #1146.

Verified per prime directive pm-v3 (memory cd8ede94). Operator-directed re-scoping confirmed in live session 2026-05-22.