What happens
tracedecay tool <graph tool> sends graph-tool operations (context, node, impact, grep, find_exact_symbol, by_qualified_name, signature, derives, ...) through dispatch_cli_graph_tool, which opens the daemon connection for the --project / cwd project only. decode_primitive_request strips project_selector as a transport key, so on origin/master (b7ab214 and later) a selector on a reader graph tool (for example tracedecay tool context --args '{"task":"...","project_selector":{"project_id":"<other>"}}') is silently answered from the handshake's project instead of the selected one.
MCP is not affected: requests/tool_dispatch.rs resolves the registered-project route and dispatches on the selected server, whose executor targets that project's graph-tool owner.
Evidence
Isolated profile with two registered projects (project and other, OTHER_MARKER exists only in other), before the refusal below:
$ tracedecay tool grep --args {"pattern":"OTHER_MARKER","fixed_strings":true,"format":"json","project_selector":{"project_id":"proj_fcc9c2c05792d4d8"}}
{"coverage":{..."visited":9},"files_scanned":1,...,"match_count":0,"results":[]}
visited: 9 is the line count of the handshake project's src/lib.rs, not other.
Status
The graph-lookup migration PR makes dispatch_cli_graph_tool refuse a project_selector with a typed config error that names --project, so the wrong-project answer is gone. What remains is routing: the CLI graph-tool path should resolve the selector to the registered project (through the daemon's registry authority, not a private database read) and hand-shake with that project, so CLI readers match MCP.
What happens
tracedecay tool <graph tool>sends graph-tool operations (context, node, impact, grep, find_exact_symbol, by_qualified_name, signature, derives, ...) throughdispatch_cli_graph_tool, which opens the daemon connection for the--project/ cwd project only.decode_primitive_requeststripsproject_selectoras a transport key, so on origin/master (b7ab214 and later) a selector on a reader graph tool (for exampletracedecay tool context --args '{"task":"...","project_selector":{"project_id":"<other>"}}') is silently answered from the handshake's project instead of the selected one.MCP is not affected:
requests/tool_dispatch.rsresolves the registered-project route and dispatches on the selected server, whose executor targets that project's graph-tool owner.Evidence
Isolated profile with two registered projects (
projectandother,OTHER_MARKERexists only inother), before the refusal below:visited: 9is the line count of the handshake project'ssrc/lib.rs, notother.Status
The graph-lookup migration PR makes
dispatch_cli_graph_toolrefuse aproject_selectorwith a typed config error that names--project, so the wrong-project answer is gone. What remains is routing: the CLI graph-tool path should resolve the selector to the registered project (through the daemon's registry authority, not a private database read) and hand-shake with that project, so CLI readers match MCP.