Persistent Codex MCP Support: ChromaDBserver fails, Claude Code works

What feature would you like to see?

Summary

When using the ChromaDB MCP server https://github.com/chroma-core/chroma-mcp, Claude Code works reliably, but Codex fails whenever the MCP tool is called. The key difference is that Codex spawns the MCP in a fresh sandbox for every tool invocation, whereas Claude launches it once and keeps the process alive. Because the Chroma server must load a sentence-transformers embedding model (BAAI/bge-small-en-v1.5), Codex’s per-call restart keeps trying to reinitialize the model; the sandboxed process cannot see the cached model and dies with “No sentence-transformers model found … Transport closed.”

Environment

• Project root contains .chroma/ (persistent Chroma DB) and bin/chroma-mcp-here wrapper.
• Model cache populated at ~/.cache/huggingface/hub/models--BAAI--bge-small-en-v1.5.
• Claude Code registered the wrapper
• Codex CLI initially ran with sandbox_mode=read-only; later switched to workspace-write, then danger-full-access.

What Works (Claude)

1. Claude reads .claude/settings.local.json and launches /path/to/bin/chroma-mcp-here once when the session starts.
2. Log lines show “Processing request … Load pretrained SentenceTransformer …” just once; the server stays up for the entire session.
3. Queries succeed: they return the ingested chunks from textbooks/ert.pdf.

What Fails (Codex)

1. Each mcp__textbooks__chroma_query_documents call launches a fresh chroma-mcp but immediately logs:

``
No sentence-transformers model found with name BAAI/bge-small-en-v1.5. Creating a new one with mean pooling.
`
followed by Transport closed`.

1. The CLI log (~/.codex/log/codex-tui.log) shows the server starting and failing for every tool call. Even after configuring HF_HOME, SENTENCE_TRANSFORMERS_HOME, and TRANSFORMERS_OFFLINE=1 through codex mcp add --env …, the sandboxed process still can’t reuse the cached model.
2. Manual retrieval via the same virtualenv works:

``python
client = chromadb.PersistentClient(path='.chroma')
result = client.get_collection('textbooks-doom_emacs_config').query(...)
``
returning the expected textbook passages.

Root Cause

Codex restarts the MCP server in a new sandbox for each tool invocation. Stateful MCPs (like Chroma) need a persistent embedding model; sandboxed per-call startups can’t reuse cached models and cannot reach external network resources. Claude’s implementation, by contrast, launches the server once per session, so the cached embeddings are loaded exactly once and reused.

Request

Please add a mode to Codex that keeps MCP servers alive across tool calls (or at least shares a persistent filesystem cache), mirroring Claude’s behaviour. Without that, any MCP that loads heavy resources (language models, embeddings, database handles) will continue to fail, even when the data is fully cached locally.

References

• .chroma/ database populated via custom script
• Wrapper: bin/chroma-mcp-here
• Cached embeddings: ~/.cache/huggingface/hub/models--BAAI--bge-small-en-v1.5
• Failing logs: ~/.codex/log/codex-tui.log

Additional information

_No response_