Skip to content

Persistent Codex MCP Support: ChromaDBserver fails, Claude Code works #6128

Closed

Description

@falloutphil

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.
  2. 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.
  3. Manual retrieval via the same virtualenv works:
    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

Activity

  1. added
    mcpIssues related to the use of model context protocol (MCP) servers
    on Nov 2, 2025
  2. added
    bugSomething isn't working
    and removed
    enhancementNew feature or request
    on Nov 15, 2025
  3. etraut-openai commented on Jan 17, 2026

    @etraut-openai
    Contributor

    Closing out old bugs.

  4. alario-tang commented on Apr 22, 2026

    @alario-tang

    Related, but I do not think this is a duplicate of #6128.

    I just filed #18977 for another Transport closed failure mode on macOS:

    • the underlying OMX operation is healthy through CLI parity
    • the downstream MCP server is intentionally coupled to stdio lifecycle and exits on stdin_end / stdin_close / transport_close
    • the visible failure seems to come from host-side MCP transport churn/drop/replacement, rather than from the need for a persistent/stateful MCP like Chroma

    So the overlap is the general MCP lifecycle theme, but the concrete trigger looks different:

    Cross-linking in case both point to broader MCP host lifecycle robustness work:
    #18977

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) servers

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions