@geminilight/mindos
npm
v1.1.66
Published by @geminilight — no publish provenance, so origin is unverified, but the source is public: the repository link below is self-declared yet readable, so you can inspect the code before adopting it.
MindOS — Human-Agent Collaborative Mind System. Local-first knowledge base that syncs your mind to all AI Agents via MCP.
The grade answers one question — how safe is this server for you to adopt — so it is computed in two auditable stages. Nothing below is an opinion or an LLM's guess; every line is a real term the deterministic engine applied, and the same input always yields the same number.
1. Threat score — 100 − 0 = 100. What the published surface and source actually contain:
The deterministic scan raised no scored threat in the surface it inspected — the threat score stayed at 100. Capability observations and advisory notes are recorded but never lower it.
2. Client adoption risk — 100 − 7 = 93. Three small, subtract-only factors that reflect your risk in adopting it — a clean scan proves less on a powerful, unverified or barely-inspectable package, so the grade says so plainly:
| Points | Adoption-risk factor |
|---|---|
| −6 | capability blast radius (high) — client exposure if the model is manipulated |
| −1 | publisher verification (public source) — no provenance, but the source is public and inspectable |
Capability observations and info notes are shown under Findings but never scored.
Open any row's finding below for the file, line and evidence behind a deduction.
In the server's implementation (`dist/protocols/mcp-server/index.cjs:5`): Evaluating strings as code is the most direct RCE primitive; if any tool input reaches it, the server executes attacker-chosen code. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: ode.process(l,t));let f=new Function(`${si.default.self}`,`${si.default.scope}`,l)(this,this.scope.get());if(this.scope.
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/protocols/mcp-server/index.cjs
In the server's implementation (`bin/mindos-shim.cjs:3`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: Process = require('node:child_process'); const crypto = require('node:crypto'); const fs = require('node:fs'); const os
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server bin/mindos-shim.cjs
In the server's implementation (`dist/agent/runtime/adapters/session-transcripts/adapters/opencode.js:1`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: { execFile } from 'node:child_process'; import { existsSync } from 'node:fs'; import { homedir } from 'node:os'; import
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/agent/runtime/adapters/session-transcripts/adapters/opencode.js
In the server's implementation (`dist/agent/runtime/claude-code-cli.js:1`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: rt { spawn } from 'node:child_process'; import { createInterface } from 'node:readline'; import { appendBoundedLog, kill
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/agent/runtime/claude-code-cli.js
In the server's implementation (`dist/agent/runtime/codex-app-server.js:1`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: rt { spawn } from 'node:child_process'; import { createInterface } from 'node:readline'; import { appendBoundedLog, kill
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/agent/runtime/codex-app-server.js
In the server's implementation (`dist/agent/runtime/codex-env.js:1`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: ecFileSync } from 'node:child_process'; import { existsSync, readFileSync } from 'node:fs'; import { homedir } from 'nod
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/agent/runtime/codex-env.js
In the server's implementation (`dist/client.js:1`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: childProcess from 'node:child_process'; import { parseMindosSseLine } from './agent/turn/index.js'; export class MindosH
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/client.js
In the server's implementation (`dist/knowledge/git/index.js:1`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: port { execFile } from 'child_process'; import { promisify } from 'util'; import { createError } from '../../foundation/
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/knowledge/git/index.js
In the server's implementation (`dist/protocols/acp/detect-local.js:4`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: e, execFileSync } from 'child_process'; import { findUserOverride, getDetectableAgents, resolveAgentCommand } from './ag
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/protocols/acp/detect-local.js
In the server's implementation (`dist/protocols/acp/index.js:1`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: execFileSync as Xh}from"child_process";function _t(e){let t=e;return e==="~"?t=xo.homedir():(e.startsWith("~/")||e.start
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/protocols/acp/index.js
In the server's implementation (`dist/protocols/acp/subprocess.js:6`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: FileSync, spawn } from 'child_process'; import { Readable, Writable } from 'node:stream'; import path from 'path'; impor
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/protocols/acp/subprocess.js
In the server's implementation (`dist/server/handlers/setup-port.js:48`): A hardcoded outbound call to a fixed external host inside server code is a classic exfiltration/telemetry channel — especially paired with reads of local data. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: const response = await fetch(`http://${host}:${port}/api/health`, { signal: AbortSignal.timeout(2000),
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/server/handlers/setup-port.js
Tool "mindos_write_file" can write, overwrite or delete files (keyword "write_file" in tool name). Verify it is scoped to a safe directory.
Fix: Constrain file operations to an explicit, non-sensitive root; reject path traversal.
Location: tool mindos_write_file
Tool "mindos_create_file" can write, overwrite or delete files (keyword "create_file" in tool name). Verify it is scoped to a safe directory.
Fix: Constrain file operations to an explicit, non-sensitive root; reject path traversal.
Location: tool mindos_create_file
Tool "mindos_batch_create_files" can write, overwrite or delete files (keyword "create_file" in tool name). Verify it is scoped to a safe directory.
Fix: Constrain file operations to an explicit, non-sensitive root; reject path traversal.
Location: tool mindos_batch_create_files
Tool "mindos_delete_file" can write, overwrite or delete files (keyword "delete_file" in tool name). Verify it is scoped to a safe directory.
Fix: Constrain file operations to an explicit, non-sensitive root; reject path traversal.
Location: tool mindos_delete_file
Tool "mindos_move_file" can write, overwrite or delete files (keyword "move_file" in tool name). Verify it is scoped to a safe directory.
Fix: Constrain file operations to an explicit, non-sensitive root; reject path traversal.
Location: tool mindos_move_file
In the server's implementation (`dist/foundation/native-import.js:21`): Loading a module chosen at runtime (from a variable) can pull in and run attacker-influenced code paths. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: on('specifier', 'return import(specifier)'); //# sourceMappingURL=native-import.js.map
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/foundation/native-import.js
In the server's implementation (`dist/protocols/mcp-server/index.cjs:38`): Loading a module chosen at runtime (from a variable) can pull in and run attacker-influenced code paths. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: 'require "%s"',n);var a=require(n).__express;if(typeof a!="function")throw new Error('Module "'+n+'" does not provide a
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/protocols/mcp-server/index.cjs
Tool "mindos_write_file" can mutate/egress but declares no destructiveHint. Clients that don't default to spec-safe behavior may not prompt before running it.
Fix: Declare accurate annotations, and gate destructive tools on user confirmation regardless.
Location: tool mindos_write_file
Tool "mindos_create_file" can mutate/egress but declares no destructiveHint. Clients that don't default to spec-safe behavior may not prompt before running it.
Fix: Declare accurate annotations, and gate destructive tools on user confirmation regardless.
Location: tool mindos_create_file
Tool "mindos_batch_create_files" can mutate/egress but declares no destructiveHint. Clients that don't default to spec-safe behavior may not prompt before running it.
Fix: Declare accurate annotations, and gate destructive tools on user confirmation regardless.
Location: tool mindos_batch_create_files
Tool "mindos_delete_file" can mutate/egress but declares no destructiveHint. Clients that don't default to spec-safe behavior may not prompt before running it.
Fix: Declare accurate annotations, and gate destructive tools on user confirmation regardless.
Location: tool mindos_delete_file
Tool "mindos_move_file" can mutate/egress but declares no destructiveHint. Clients that don't default to spec-safe behavior may not prompt before running it.
Fix: Declare accurate annotations, and gate destructive tools on user confirmation regardless.
Location: tool mindos_move_file
Tool "mindos_read_file" takes a path parameter "path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.
Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.
Location: tool mindos_read_file · inputSchema.properties.path
Tool "mindos_write_file" takes a path parameter "path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.
Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.
Location: tool mindos_write_file · inputSchema.properties.path
Tool "mindos_create_file" takes a path parameter "path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.
Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.
Location: tool mindos_create_file · inputSchema.properties.path
Tool "mindos_batch_create_files" takes a path parameter "path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.
Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.
Location: tool mindos_batch_create_files · inputSchema.properties.path
Tool "mindos_delete_file" takes a path parameter "path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.
Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.
Location: tool mindos_delete_file · inputSchema.properties.path
Tool "mindos_move_file" takes a path parameter "from_path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.
Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.
Location: tool mindos_move_file · inputSchema.properties.from_path
Tool "mindos_move_file" takes a path parameter "to_path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.
Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.
Location: tool mindos_move_file · inputSchema.properties.to_path
Tool "mindos_read_lines" takes a path parameter "path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.
Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.
Location: tool mindos_read_lines · inputSchema.properties.path
Tool "mindos_get_file_at_version" takes a path parameter "path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.
Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.
Location: tool mindos_get_file_at_version · inputSchema.properties.path
Each tool and what it can reach — statically extracted from the published source.
mindos_batch_create_fileswrites filesmindos_create_filewrites filesmindos_delete_filewrites filesmindos_get_file_at_versionreads sensitive datamindos_list_filesreads sensitive datamindos_move_filewrites filesmindos_read_filereads sensitive datamindos_read_linesreads sensitive datamindos_write_filewrites filesmindos_append_csvno sensitive capabilitymindos_append_to_fileno sensitive capabilitymindos_bootstrapno sensitive capabilitymindos_compileno sensitive capabilitymindos_create_spaceno sensitive capabilitymindos_dreamingno sensitive capabilitymindos_get_backlinksno sensitive capabilitymindos_get_historyno sensitive capabilitymindos_get_recentno sensitive capabilitymindos_insert_after_headingno sensitive capabilitymindos_insert_linesno sensitive capabilitymindos_lintno sensitive capabilitymindos_list_spacesno sensitive capabilitymindos_rename_fileno sensitive capabilitymindos_rename_spaceno sensitive capabilitymindos_search_notesno sensitive capabilitymindos_update_linesno sensitive capabilitymindos_update_sectionno sensitive capabilityScan history per published version. The engine is deterministic — the same version always yields the same score, so a changed score means the package itself changed.
| Version | Score | Findings | Engine | Scanned |
|---|---|---|---|---|
v1.1.66 latest |
A 93/100 | 33 | 1.13.0 | 2026-09-07 |
v1.1.62 |
A 93/100 | 33 | 1.13.0 | 2026-09-01 |
v1.1.61 |
A 100/100 | 13 | 1.5.0 | 2026-07-22 |
Show this server's live Trust Score in your README, docs or website. The badge is served straight from the registry and updates automatically after every rescan — no API key needed. It links back to this page, so anyone who sees the grade can also read the findings behind it instead of taking a number on faith.
The score above is reproducible: the same package version always yields the same result. Run it locally or over the free API — no account, no LLM, fully deterministic.
npx mcptrustchecker scan @geminilight/mindos --online
FDA device & vehicle recall risk for AI agents: recall history, MAUDE trend, risk score.
Open-source MCP server exposing Agent402.Tools' catalog — 500+ strong: 400+ self-hostable tools + 100 multi-tool skill packs (security-audit, trend-analysis, structured-scrape, decode-blob, forecasting-bake-off) for AI agents — browser, web search & answe
Zero-dependency MCP server that gives AI agents a self-updating project memory in AGENTS.md. Returns merge instructions instead of mutating state, so every change is a reviewable diff.
MCP Apps UI resources and server helpers for n8n
MCP server providing comprehensive access to BookStack knowledge management system
MCP server for tracking achievements with STAR methodology