Index worker loses requesting session's allowed root with an existing daemon (0.10.5, Windows)

[samartomar]

Problem

Native codebase-memory-mcp 0.10.5 on Windows 11 rejects indexing a new consumer root when it joins an existing account daemon started with a different CBM_ALLOWED_ROOT. Both clients use the exact same CBM_CACHE_DIR; the new client sets its own allowed root to the exact repository being indexed. list_projects succeeds, but index_repository returns outside the allowed root and recommends an account-level allow-root grant.

Reproduction outline

1. Start a normal MCP session for disposable repository A, with CBM_ALLOWED_ROOT=A and a canonical cache C. Keep that session alive.
2. From disposable repository B outside A, use the same installed build and cache C, with CBM_ALLOWED_ROOT=B.
3. Invoke codebase-memory-mcp cli list_projects: succeeds.
4. Invoke codebase-memory-mcp cli index_repository --repo-path B --mode moderate: rejects B as outside the allowed root.

Observed build fingerprint: f8aee1683f94f7598ae70640a588f27d51811433f046b39c1faf186c17010739. The initial session and existing daemon were preserved. No grants were added and no sandbox settings were relaxed.

Suspected source path

• main.c routes ordinary CLI tool calls through the daemon and supplies per-client root context.
• application.c starts an index worker using args, memory budget and output paths; the worker interface does not carry the allowed root.
• index_supervisor.c spawns the physical worker with inherited environment.
• The standalone worker server falls back to process CBM_ALLOWED_ROOT in mcp.c.

The source path suggests that the physical worker rechecks the daemon starter's boundary instead of the requesting session's boundary. Worker environment memory was not instrumented; this is a source-based explanation of the observed rejection.

Expected fix and acceptance

Propagate validated request-session authorization to the physical worker without mutating the daemon's shared process environment. Test concurrent A/B sessions: each can index its own allowed root, an out-of-policy request remains denied, and starting/restarting B leaves A usable. Do not require users to widen global grants merely to preserve the documented session-specific boundary.

The configuration documentation also says ordinary one-shot CLI tools do not connect to/start a daemon, while the pinned source above routes them through it. Reconcile that ownership description with executable behavior.

Separate observation

A later two-file fixture within the daemon starter's existing root launched an index worker but did not return within a 120-second bound. Its task-owned processes exited after timeout; the original daemon remained alive. That timeout is not yet diagnosed and is not claimed to have the same cause as the root rejection.