execute.py installs deps only in agent venv, no auto-start for MCP servers (Docker)

[grodingo]

Bug Description

The Context Engine plugin has three related issues when running inside the Agent Zero Docker container:

1. Dual-venv dependency installation

In Docker, Agent Zero uses two separate Python venvs:

• /opt/venv — agent runtime (used by execute.py via sys.executable)
• /opt/venv-a0 — framework runtime (used by extensions and tools)

execute.py installs all dependencies (qdrant_client, fastembed, tree-sitter, etc.) using sys.executable, which resolves to /opt/venv/bin/python3. The framework runtime (/opt/venv-a0) never gets the deps.

Impact: Plugin UI reports success but tools/extensions fail at runtime with ModuleNotFoundError.

# execute.py line ~104
proc = subprocess.run(
    [sys.executable, "-m", "pip", "install", "-q", ...] + _EMBEDDED_DEPS,
    ...)

2. No auto-start mechanism for MCP servers

execute.py starts memory_server.py and indexer_server.py as background processes with PID files in .pids/. When the Docker container restarts:

• Processes are gone
• PID files become stale (pointing to dead PIDs)
• There is no mechanism in hooks.py or extensions to auto-restart the servers
• The _10_ce_init.py extension tries to connect but silently fails if servers are down

Impact: Users must manually re-run execute.py from the plugin UI after every container restart.

3. Qdrant storage conflict

When both servers are running and accessing the same Qdrant storage path, the embedded mode produces repeated errors:

ERROR:__main__:memory_find failed: Storage folder /a0/.codebase/qdrant_storage is already accessed by another instance of Qdrant client. If you require concurrent access, use Qdrant server instead.

Both memory_server.py and indexer_server.py instantiate their own QdrantClient pointing to the same local path. The embedded Qdrant client does not support concurrent access from multiple processes.

Steps to Reproduce

1. Run Agent Zero in Docker (Podman with overlay filesystem)
2. Install the Context Engine plugin
3. Click "Execute" in the plugin UI
4. Observe: installation succeeds, servers start, everything works
5. Restart the Docker container
6. Observe: all deps gone from /opt/venv (overlay not persisted), servers not running
7. Only /a0 (bind mount) persists — the .pids/ directory still contains stale PID files

Environment

• Agent Zero in Docker (Podman, overlay filesystem)
• /opt/venv: Python 3.13 (agent runtime, NOT bind-mounted)
• /opt/venv-a0: Python 3.12 (framework runtime, NOT bind-mounted)
• /a0: bind mount (btrfs, persisted)
• Plugin version: Context Engine 1.0.0

Suggested Fixes

Fix 1: Install deps in both venvs

def _install_deps() -> bool:
    # Install in current venv
    _pip_install(sys.executable)
    
    # In Docker, also install in framework venv
    framework_python = Path("/opt/venv-a0/bin/python3")
    if framework_python.exists() and str(framework_python) != sys.executable:
        _pip_install(str(framework_python))

Fix 2: Auto-start servers on container startup

Add server health-check + auto-start logic to hooks.py or _10_ce_init.py:

# In _10_ce_init.py or a new extension
async def execute(self, loop_data, **kwargs):
    if not self._servers_running():
        await self._start_servers()

Alternatively, document that users should add the execute.py command to their container startup script.

Fix 3: Resolve Qdrant concurrent access

• Option A: Use a single Qdrant server process that both memory and indexer share
• Option B: Use separate collection names but a shared Qdrant server instance
• Option C: Switch to Qdrant server mode instead of embedded local path mode

[TerminallyLazy]

I'll take a look, thanks.