[BUG] A project's .env LOG_LEVEL Interferes with basic-memory

[jpmurray]

When adding a new project using uvx basic-memory project add project-name '~/path/project/memory', the process fails if the project's directory contains a dotenv file (ie. : ~/path/project/.env) with a LOG_LEVEL=debug entry. It seems basic-memory reads this environment variable and expects the value to be uppercase, causing an error. I'm personally encountering this with a Laravel project, but I'm expecting a lot more instance could be found of a dotenv file with this value.

This is problematic especially when using it as MCP in editors like Roo Code's mcp.json, as it seems it will run the uvx command in the root of its project, and it then catches said project's .env, failing to start because of the above.

Steps to Reproduce

1. Create a folder with a .env file (~/path/project/.env)
2. Add a line to .env: LOG_LEVEL=debug
3. Add a project : uvx basic-memory project add project-name '~/path/project/memory'
4. cd ~/path/project && uvx basic-memory project list should be failing.
5. For my Roo Code example, having a ~/path/project/.roo/mcp.json with basic-memory in it will fail if the LOG_LEVEL value is present and lowercase.

Expected Behavior

basic-memory should not be affected by environment variables defined in a project's .env file, especially if they are unrelated to basic-memory's functionality. The project should be added successfully, regardless of the log level value or casing.

What could be done

Make it so basic-memory accepts the debug string regardless of casing.

Prefix BM's environment variables names could be an option too.

[phernandez]

@claude I suspect the user is running basic-memory from a directory containing an .env file. This is problematic, because if the dir a source repository for code, then basic-memory will get very confused about properties in the file. Should we remove the .env loading from the config?

[claude]

Claude finished @phernandez's task —— View job

---

Analysis Complete - Root Cause Found

I've identified the root cause of the .env interference issue. Here's what's happening:

🔍 The Problem

In /src/basic_memory/config.py, the BasicMemoryConfig class has:

model_config = SettingsConfigDict(
    env_prefix="BASIC_MEMORY_",
    extra="ignore",
    env_file=".env",  # ← This is the problem!
    env_file_encoding="utf-8",
)

Line 86: env_file=".env" automatically loads ALL variables from any .env file in the current working directory
Line 84: env_prefix="BASIC_MEMORY_" only applies to environment variables, not .env file variables

💡 The Issue Flow

1. User runs basic-memory from a project directory containing .env with LOG_LEVEL=debug
2. Pydantic automatically loads the .env file and sets config.log_level = "debug"
3. Later, when logging is initialized, it expects uppercase log levels like "DEBUG", "INFO", etc.
4. The validation fails because "debug" (lowercase) is not a valid log level

🛠️ Recommendation

I recommend removing the automatic .env file loading entirely for these reasons:

1. Separation of concerns: A project's .env file should not affect basic-memory's configuration
2. Predictable behavior: Users can still set basic-memory config via:
   • Environment variables with BASIC_MEMORY_ prefix
   • The ~/.basic-memory/config.json file
   • Command line arguments
3. Security: Prevents accidental config pollution from unrelated projects

📝 Proposed Fix

model_config = SettingsConfigDict(
    env_prefix="BASIC_MEMORY_",
    extra="ignore",
    # Remove env_file=".env" entirely
    env_file_encoding="utf-8",
)

This change would:

• ✅ Fix the LOG_LEVEL interference issue
• ✅ Make behavior more predictable
• ✅ Still allow proper configuration via environment variables with the BASIC_MEMORY_ prefix
• ✅ Maintain backward compatibility for users who set environment variables correctly

🤔 Alternative Solutions

If you want to keep .env support, we could:

1. Add case-insensitive log level validation
2. Use a specific .env filename like .basic-memory.env
3. Add prefix filtering to .env variables

But I believe removing it entirely is the cleanest solution.

Should I implement this fix?

---

[phernandez]

@claude yes, make PR to remove the .env loading from the config

[claude]

Claude encountered an error —— View job

---

Fix: Remove .env loading from BasicMemoryConfig

Todo List:

• Read current config.py file to understand the structure
• Remove env_file=".env" from BasicMemoryConfig.model_config
• Install dependencies and run quality checks
• Test changes work properly
• Commit and push changes
• Generate PR URL

✅ Change applied: Removed env_file=".env" from BasicMemoryConfig.model_config in /src/basic_memory/config.py:86

This prevents basic-memory from automatically loading .env files from the current working directory, which was causing LOG_LEVEL interference issues.

Installing dependencies and running quality checks...

---

[jpmurray]

I'm not sure I'm autorized to do that but... @claude seems to be stuck on the task, maybe you can restart, @phernandez ?

[phernandez]

@claude can you try your PR fix again?

[claude]

Claude finished @phernandez's task —— View job • Create PR ➔

---

Fix: Remove .env loading from BasicMemoryConfig

Todo List:

• Read current config.py file to understand the structure
• Remove env_file=".env" from BasicMemoryConfig.model_config
• Install dependencies and run quality checks
• Test changes work properly
• Commit and push changes
• Generate PR URL

✅ Change applied: Removed env_file=".env" from BasicMemoryConfig.model_config in /src/basic_memory/config.py:86

This prevents basic-memory from automatically loading .env files from the current working directory, which was causing LOG_LEVEL interference issues.

⚠️ Permission Issue: I don't have Bash permissions to run quality checks or git commands. The fix is ready, but you'll need to:

1. Run quality checks: just check (or just lint, just format, just type-check, just test)
2. Commit the changes: git add src/basic_memory/config.py && git commit -m "fix: remove .env file loading from BasicMemoryConfig"
3. Push: git push origin claude/issue-227-20250722-1856

Manual PR Creation URL:

---

[voltageek]

So, I'm new to basic-memory and I've been struggling with this bug (specifically, running basic-memory in a directory with an existing .env file causes the following error:

pydantic_core._pydantic_core.ValidationError: 1 validation error for Settings

I tried commenting out the env_file=".env" line in config.py proposed by claude but that didn't resolve the issue. Narrowed it down to the fastmcp package loading the env file via the pydantic BaseSettings object (See: https://github.com/jlowin/fastmcp/blob/a01beb4e1caffb752ffeca6de37b2d83549d32e8/src/fastmcp/settings.py#L82C9-L82C17). Commenting that out in fastmcp without modifying config.py works. Hope that is helpful.