[Bug]: v0.0.8 self-hosted memory generation fails with No model provider configured while doctor detects OpenAI

Bug description

On supermemory-server v0.0.8 self-hosted, documents are accepted, extracted and stored, but memory generation consistently fails with:

[llm] No model provider configured
WARN [Workflow] Self-hosted memory agent failed for document, skipping memory generation
[Workflow] Document <id> finalized: 1 chunks, 0 memories (memory generation failed)

This happens even though:

• supermemory-server doctor detects the OpenAI LLM provider.
• doctor reports all checks passed.
• OPENAI_API_KEY is present in the running server process environment.
• The server was also tested after explicitly injecting OPENAI_API_KEY at launch.
• Restarting the server does not resolve the issue.

The Web UI stores the documents successfully but continues to show 0 memories.

Environment

supermemory-server: v0.0.8
Platform: linux-x64
Bun: 1.3.4
Storage: encrypted local storage
HTTP server: localhost:6767
Python SDK: supermemory 3.59.0

Official Linux x64 binary checksum was verified:

SHA-256:
87f32433d0179be80bb9d8a1bafbabc65af4128324342a27ecd8bd1a77b5506f

Result:
MATCH

So the installed binary matches the official server-v0.0.8 release.

doctor output

With the server running:

supermemory doctor · v0.0.8
linux-x64 · bun 1.3.4

✓ data directory
✓ store              encrypted snapshot present
✓ storage key        store unlocks
✓ llm provider       openai
✓ embeddings         openai · text-embedding-3-small · 1536d
✓ remote creds       openai embedding credentials resolve
✓ port               a server is already running on 6767
✓ workflow engine    rivet engine responding
✓ lite usage

Result:

all checks passed

Steps to reproduce

1. Configure OpenAI as the provider using the Supermemory setup.
2. Start the server:

supermemory-server

1. Confirm:

supermemory-server doctor

reports:

llm provider    openai
all checks passed

1. Add a fresh document using the Python SDK:

import os
import uuid
from supermemory import Supermemory

client = Supermemory(
    api_key=os.environ["SUPERMEMORY_API_KEY"],
    base_url="http://localhost:6767",
)

marker = f"provider-test-{uuid.uuid4()}"

result = client.add(
    content=f"Supermemory provider diagnostic. Unique marker: {marker}",
    container_tag="diagnostic",
)

print(result)

1. SDK returns successfully:

AddResponse(..., status='queued')

1. The server processes the document but fails during the memory-agent stage.

Actual server behaviour

The document is accepted and chunk extraction begins:

[Extraction] Extracted with text
[Workflow] Document <id> embedding 1 chunks (1 batches)
[Workflow] Document <id> stored 1 embedded chunks
[Workflow] Document <id> starting memory agent (1 chunks)

The memory agent then fails:

[llm] No model provider configured. Set OPENAI_API_KEY
(with optional OPENAI_BASE_URL + OPENAI_MODEL for OpenAI-compatible endpoints),
ANTHROPIC_API_KEY, GEMINI_API_KEY, or GROQ_API_KEY

Followed by:

WARN [Workflow] Self-hosted memory agent failed for document, skipping memory generation
[Workflow] Document <id> finalized: 1 chunks, 0 memories (memory generation failed)

Explicit environment-variable test

To rule out an encrypted-credential loading problem, I stopped the server and launched it with the OpenAI key explicitly supplied to the process.

The running process was then checked through /proc/<pid>/environ:

OPENAI_API_KEY=<set>

A completely new unique document was submitted afterward.

Memory generation still resulted in 0 memories.

Therefore, the failure does not appear to be caused simply by the server process missing OPENAI_API_KEY.

Web UI result

After three diagnostic submissions:

Documents: 3
Memories: 0

Each document is visible in the Web UI and shows:

0 memories

So ingestion/storage works, but the memory-agent stage does not.

Additional observation: embedding configuration mismatch

There is also a difference between doctor and the running server:

doctor reports:

embeddings    openai · text-embedding-3-small · 1536d

while server startup reports:

embeddings    local · Xenova/bge-base-en-v1.5 · 768d

This may be a separate issue and appears related to existing issue #1336 regarding embedding configuration being ignored.

The primary blocker in this report is the LLM provider / memory-agent failure.

Expected behaviour

When:

supermemory-server doctor

reports:

llm provider    openai
all checks passed

and OPENAI_API_KEY is available to the running process, the memory agent should initialise the OpenAI provider and generate memories from successfully ingested documents.

At minimum, doctor and the runtime memory-agent provider registry should agree on whether an LLM provider is actually available.

Actual behaviour

The health check reports a valid OpenAI provider, while the runtime memory agent behaves as if no provider exists:

doctor: llm provider openai
runtime: [llm] No model provider configured

This state is reproducible across server restarts and remains reproducible when OPENAI_API_KEY is explicitly injected into the server process.

Related issues

• #1208 — similar self-hosted LLM-provider registry failure, but reported against an older server version and currently closed.
• #1336 — embedding provider configuration ignored / local Xenova embedding used despite configuration.

This may be a regression or a related provider-initialisation issue affecting v0.0.8.