Memory embeddings auth-path issue
Hi!
— looking for help with a memory embeddings auth-path issue while keeping Codex OAuth as primary chat model.
Setup
• OpenClaw: 2026.2.9
• OS: Windows 11
• Primary chat model: openai-codex/gpt-5.3-codex via Codex OAuth
• Memory was initially configured for remote OpenAI embeddings (text-embedding-3-small)
Goal
• Keep Codex OAuth for chat/completions
• Use OpenAI API key for memory embeddings (or cleanly split auth paths)
Observed behavior
• memory_search/memory sync repeatedly failed with: • openai embeddings failed: 502 {"error":{"message":"Failed to authenticate request with Clerk","code":502}}
• Also saw intermittent SQLite rename lock warnings during reindex attempts: • EBUSY: resource busy or locked, rename ...main.sqlite...
Important detail
• Direct calls to OpenAI embeddings endpoint worked from host shell, so API key itself appears valid.
Already tried
• Explicit config pinning: • agents.defaults.memorySearch.provider = openai
• agents.defaults.memorySearch.remote.baseUrl = https://api.openai.com/v1
• agents.defaults.memorySearch.remote.apiKey = <OPENAI_API_KEY>
• batch disabled
• Auth order override to prefer openai:manual
• Gateway restart + openclaw doctor --fix
Current workaround (works)
• Switched memory embeddings to local: • agents.defaults.memorySearch.provider = local
• local model embeddinggemma-300M-Q8_0.gguf
• Current status now healthy (Embeddings: ready, vector/FTS ready)
Questions
1. Is there a known bug where memory embeddings can still hit a Clerk/Codex auth path despite explicit memorySearch.remote.* OpenAI config?
2. Recommended clean pattern for “Codex OAuth for chat + OpenAI token for memory embeddings”?
3. Best practice for avoiding/recovering transient EBUSY sqlite rename during active sync/reindex?
Happy to share sanitized config snippets/log excerpts if helpful.
— looking for help with a memory embeddings auth-path issue while keeping Codex OAuth as primary chat model.
Setup
• OpenClaw: 2026.2.9
• OS: Windows 11
• Primary chat model: openai-codex/gpt-5.3-codex via Codex OAuth
• Memory was initially configured for remote OpenAI embeddings (text-embedding-3-small)
Goal
• Keep Codex OAuth for chat/completions
• Use OpenAI API key for memory embeddings (or cleanly split auth paths)
Observed behavior
• memory_search/memory sync repeatedly failed with: • openai embeddings failed: 502 {"error":{"message":"Failed to authenticate request with Clerk","code":502}}
• Also saw intermittent SQLite rename lock warnings during reindex attempts: • EBUSY: resource busy or locked, rename ...main.sqlite...
Important detail
• Direct calls to OpenAI embeddings endpoint worked from host shell, so API key itself appears valid.
Already tried
• Explicit config pinning: • agents.defaults.memorySearch.provider = openai
• agents.defaults.memorySearch.remote.baseUrl = https://api.openai.com/v1
• agents.defaults.memorySearch.remote.apiKey = <OPENAI_API_KEY>
• batch disabled
• Auth order override to prefer openai:manual
• Gateway restart + openclaw doctor --fix
Current workaround (works)
• Switched memory embeddings to local: • agents.defaults.memorySearch.provider = local
• local model embeddinggemma-300M-Q8_0.gguf
• Current status now healthy (Embeddings: ready, vector/FTS ready)
Questions
1. Is there a known bug where memory embeddings can still hit a Clerk/Codex auth path despite explicit memorySearch.remote.* OpenAI config?
2. Recommended clean pattern for “Codex OAuth for chat + OpenAI token for memory embeddings”?
3. Best practice for avoiding/recovering transient EBUSY sqlite rename during active sync/reindex?
Happy to share sanitized config snippets/log excerpts if helpful.
The AI that actually does things. Emails, calendar, home automation - all from your favorite chat app. New shell, ready to help. The lobster way.
131,281Members
Resources
Similar Threads
Was this page helpful?
