You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched existing issues and this is not a duplicate
I understand this issue needs status:approved before a PR can be opened
📝 Bug Description
Engram resolves the active project differently depending on the transport or first-party client. The canonical filesystem/Git/.engram/config.json detector exists in internal/project, but the complete policy for explicit selection, sessions, process defaults, store validation, global scope, and ambiguity recovery is coupled to MCP handlers.
This creates observable cross-client inconsistencies:
MCP applies the richest project-resolution policy.
HTTP treats an omitted project as global scope in multiple routes.
CLI search is global without a project selector, and CLI save can persist an empty project.
Pi native detects a project for context but does not apply it to mem_search when project is omitted.
Claude Code, Codex, and OpenCode duplicate simplified Git/basename detection and can diverge from .engram/config.json and canonical ambiguity handling.
🔄 Steps to Reproduce
Use a repository where canonical project detection matters, such as one configured through .engram/config.json, a worktree, or an ambiguous basename.
Run equivalent omitted-project operations through MCP, HTTP, CLI, and Pi native.
Compare the selected scope and project used by each path.
Run the Claude Code, Codex, or OpenCode adapters from the same repository.
Observe that equivalent requests can resolve to different projects or to global scope depending on the transport/client.
✅ Expected Behavior
All first-party transports and clients should share one explicit project-resolution contract:
An explicit project selector takes precedence.
Global/all-project scope is requested explicitly with a structured selector, not a magic project name.
When neither is supplied, Engram resolves the current project using one canonical policy.
MCP, HTTP, CLI, Pi native, Claude Code, Codex, and OpenCode expose consistent precedence, validation, ambiguity, and error behavior.
Adapters provide trusted context but do not independently reimplement Git/configuration/project detection.
❌ Actual Behavior
Resolution policy is fragmented. MCP contains policy unavailable to HTTP and CLI, Pi native search can become global despite detecting a project, and several adapters maintain their own simplified detectors. Equivalent user actions therefore have transport-dependent scope and project identity.
Operating System
Linux (Arch/Manjaro)
Engram Version
Development revision 509e676
Agent / Client
Other — cross-client: MCP, HTTP, CLI, Pi native, Claude Code, Codex, and OpenCode
📋 Relevant Logs
No single runtime error is emitted; the defect is inconsistent project selection and query scope across equivalent client operations.
💡 Additional Context
Proposed implementation boundary
Extract a transport-neutral resolver in Go.
Define explicit project, auto/current project, and all-project scope as separate structured concepts.
Migrate MCP first, then HTTP and CLI, followed by Pi native.
Thin Claude Code, Codex, and OpenCode adapters so they delegate canonical resolution rather than duplicate it.
Preserve compatibility intentionally and add cross-transport parity tests.
📋 Pre-flight Checks
status:approvedbefore a PR can be opened📝 Bug Description
Engram resolves the active project differently depending on the transport or first-party client. The canonical filesystem/Git/
.engram/config.jsondetector exists ininternal/project, but the complete policy for explicit selection, sessions, process defaults, store validation, global scope, and ambiguity recovery is coupled to MCP handlers.This creates observable cross-client inconsistencies:
searchis global without a project selector, and CLIsavecan persist an empty project.mem_searchwhenprojectis omitted..engram/config.jsonand canonical ambiguity handling.🔄 Steps to Reproduce
.engram/config.json, a worktree, or an ambiguous basename.✅ Expected Behavior
All first-party transports and clients should share one explicit project-resolution contract:
❌ Actual Behavior
Resolution policy is fragmented. MCP contains policy unavailable to HTTP and CLI, Pi native search can become global despite detecting a project, and several adapters maintain their own simplified detectors. Equivalent user actions therefore have transport-dependent scope and project identity.
Operating System
Linux (Arch/Manjaro)
Engram Version
Development revision
509e676Agent / Client
Other — cross-client: MCP, HTTP, CLI, Pi native, Claude Code, Codex, and OpenCode
📋 Relevant Logs
No single runtime error is emitted; the defect is inconsistent project selection and query scope across equivalent client operations.
💡 Additional Context
Proposed implementation boundary
Related issues
detect_projectignores configuration.Historical precedents include #303, #312, #280, and #345.
Acceptance criteria