muninn

Things to check before installing or enabling Muninn: - Verify the npm package contents: confirm that the published muninn-core package actually includes the native 'cxp' binary (for your platform) or documents how to obtain it. If the binary is missing, CXP operations will fail. - Inspect and approve repository modifications: Muninn will create/modify .muninn/, append enforcement blocks to files like CLAUDE.md, .cursorrules, .antigravityrules, and update .gitignore. If you don't want automated edits to project files, do not install or run in production repos. - Review the code that auto-injects context: middleware silently enriches many tool calls (filesystem, git, command execution). Make sure you are comfortable with automatic context injection into tools and responses. - Test in an isolated environment first: run Muninn in a disposable repo or VM to observe behavior (indexing, watcher, file writes) and confirm no unexpected network activity. - Audit the native binary if present: if the package includes a precompiled Rust binary, verify its provenance (publisher, checksums, or GitHub release) before executing native code. - If you need stricter control, require explicit user-invocation for context operations or run with limited permissions and avoid projects with sensitive files until you're confident in behavior. Why 'suspicious' (medium confidence): most behaviors align with a local memory engine, but the missing/assumed native binary and the automatic, persistent modifications to repo files plus wide interception of tool calls are design choices that can be misused or surprising. Additional information (actual npm release contents, presence of the cxp binary, or upstream repository with release tags and checksums) would raise confidence to 'high' and likely move this to 'benign'.