Chroma MCP: .env file ignored (set CHROMA_DOTENV_PATH to the absolute path)

TL;DR: Your .env file is not being read because the MCP server looks for it in its own working directory, not yours. Set CHROMA_DOTENV_PATH to the absolute path of your .env file, or put the variables directly in the client config env block.

(env vars silently ignored; server behaves as if CHROMA_HOST etc. were unset)

Fix it

1. Option A, absolute dotenv path. In the client config env block:

{
  "env": {
    "CHROMA_DOTENV_PATH": "[HOME]/..."
  }
}

2. Option B, skip the file. Put the variables directly in the env block:

{
  "env": {
    "CHROMA_CLIENT_TYPE": "http",
    "CHROMA_HOST": "YOUR_CHROMA_HOST",
    "CHROMA_PORT": "8000"
  }
}

3. Restart the MCP client.

   Expected: the server picks up the configured values. Connection succeeds.

When to use this

• Variables in .env work when you run the server by hand but are ignored under the MCP client.
• The server behaves as if no configuration was given.

When NOT to use this

• The values are wrong. A loaded-but-wrong value fails differently (auth errors, connection refused to the wrong host).
• You already use the env block. Then the file is irrelevant.

Compatibility

• chroma-mcp with dotenv support.

Why it happens

Relative dotenv paths resolve against the process working directory. Your terminal's directory and the MCP server's directory are different things (GUI clients often use the app bundle or system root). The default .chroma_env lookup misses, the server falls back to defaults, and nothing tells you the file was skipped.

Edge cases

• The dotenv path itself must be absolute. A relative CHROMA_DOTENV_PATH has the same problem one level up.
• Command-line args beat env vars beat dotenv. If both are set, args win. Check for conflicts.
• Secrets in a .env file are still secrets. Keep the file out of git.