Bug Description
The Codex plugin starts its long-running MCP server with uvx --prerelease=allow basic-memory mcp. If uv removes or replaces that resolved archive while Codex is still running, the server process remains alive but later lazy imports fail because its Python paths point into a directory that no longer exists.
This leaves Basic Memory tools unavailable until Codex is restarted or the missing cache path is restored.
Steps To Reproduce
- Install Basic Memory 0.23.2 and the Codex plugin with
bm install codex.
- Start Codex and invoke a Basic Memory MCP tool successfully.
- Allow the uv archive backing the running
uvx process to be removed or replaced by cache maintenance.
- Invoke a Basic Memory MCP tool that imports a module which was not already loaded.
Expected Behavior
The installed Codex plugin should keep serving MCP tools for the lifetime of the Codex process, independently of later uv cache maintenance.
Actual Behavior
The MCP call fails with:
No module named 'fastmcp.server.extensions'
Process inspection showed that the running server's executable and import paths referenced a missing directory under uv's archive cache. A fresh uvx --prerelease=allow basic-memory mcp resolution at the same Basic Memory version contained the module and completed MCP initialize and tools/list successfully.
Environment
- OS: Linux aarch64
- Python version: 3.14.6
- Basic Memory version: 0.23.2
- FastMCP version: 4.0.0b1
- Installation method: uv tool, followed by
bm install codex
- Codex plugin MCP command:
uvx --prerelease=allow basic-memory mcp
Additional Context
bm update reported 0.23.2 as current, so there is no released update that avoids this failure. Restoring the missing archive path to an identical freshly resolved environment recovered the live MCP session, which confirms the cache-path dependency, but that is only a temporary workaround.
Possible Solution
Launch the MCP server through the persistent basic-memory console executable installed by the supported bm install codex workflow. The direct repository/plugin installation instructions should state that Basic Memory must already be installed and available on PATH. A packaging test should assert that the plugin does not regress to an ephemeral uvx launcher.
Bug Description
The Codex plugin starts its long-running MCP server with
uvx --prerelease=allow basic-memory mcp. If uv removes or replaces that resolved archive while Codex is still running, the server process remains alive but later lazy imports fail because its Python paths point into a directory that no longer exists.This leaves Basic Memory tools unavailable until Codex is restarted or the missing cache path is restored.
Steps To Reproduce
bm install codex.uvxprocess to be removed or replaced by cache maintenance.Expected Behavior
The installed Codex plugin should keep serving MCP tools for the lifetime of the Codex process, independently of later uv cache maintenance.
Actual Behavior
The MCP call fails with:
Process inspection showed that the running server's executable and import paths referenced a missing directory under uv's archive cache. A fresh
uvx --prerelease=allow basic-memory mcpresolution at the same Basic Memory version contained the module and completed MCPinitializeandtools/listsuccessfully.Environment
bm install codexuvx --prerelease=allow basic-memory mcpAdditional Context
bm updatereported 0.23.2 as current, so there is no released update that avoids this failure. Restoring the missing archive path to an identical freshly resolved environment recovered the live MCP session, which confirms the cache-path dependency, but that is only a temporary workaround.Possible Solution
Launch the MCP server through the persistent
basic-memoryconsole executable installed by the supportedbm install codexworkflow. The direct repository/plugin installation instructions should state that Basic Memory must already be installed and available onPATH. A packaging test should assert that the plugin does not regress to an ephemeraluvxlauncher.