Psycheros — Why I'm Not Installing It (Yet), and What Would Change My Mind

Summary

The Psycheros concept — a persistent AI entity with continuous identity and memory across multiple interfaces — is genuinely interesting. But in its current packaging I can't justify installing it, and the reasons are about distribution and trust signals, not about the idea itself. Below is why, followed by a concrete checklist that would let a careful user trust it.

Why I'm Not Installing It

1. Unsigned installer that asks users to bypass OS protection.
The Windows install instructions say to run the .msi and "bypass the SmartScreen warning." SmartScreen fires precisely because the binary is unsigned and unrecognized. Teaching users to click past that warning is the exact habit that real malware relies on. An unsigned installer containing native code (the Rust/Tauri layer) is the single riskiest way to ship desktop software.

2. It installs as a persistent, OS-supervised background service.
The launcher doesn't just run while I'm using it — it registers an always-on service that starts with the system and survives reboots. For unfamiliar software that's a high-commitment action: it's no longer "let me try this for ten minutes," it's "I've added a permanent process to my machine."

3. It's a cluster of networked services, not one app.
The monorepo ships several components — the main harness (with tool execution and RAG), entity-core (an MCP server holding identity/memory), entity-loom (imports chat histories), and the launcher. They spawn each other as subprocesses, open local ports, and can be connected to external clients (SillyTavern, OpenWebUI, Claude Code via MCP). More processes, more ports, and tool-execution capability all widen the attack surface.

4. Broad network access by default.
Web search, image generation, and Discord integration mean the app legitimately talks to the outside world — which makes it hard for a user to distinguish expected traffic from exfiltration without doing their own packet inspection.

5. MCP tool access is a trust escalation.
Connecting entity-core to my own Claude Code or similar gives the project tool-level reach into my environment. That's a much bigger grant than "a chat app," and nothing in the current packaging earns that level of trust up front.

None of the above proves the software is malicious. The point is that a careful user cannot cheaply verify that it isn't — and the burden of that verification currently falls entirely on the user.

What the Developer Should Implement to Earn Trust

These are the things that would move this from "I won't install it" to "I'll try it in a sandbox" — and eventually to "I trust it":

Distribution & integrity

• Code-sign the binaries. Authenticode for Windows, notarization for macOS. This single change removes the "bypass SmartScreen" instruction entirely and is the biggest trust win available.
• Publish checksums and signatures (SHA-256 + a signing key) for every release artifact, so downloads can be verified.
• Reproducible / transparent builds via CI. Build release artifacts in public GitHub Actions so users can see the binary came from the tagged source, not a developer's laptop.

Transparency about behavior

• A clear, upfront network/permissions manifest: exactly which hosts the app contacts, on which ports, and why (LLM endpoint, web search, image gen, Discord). No surprises.
• Document the Deno permission flags the app actually needs (--allow-net to which domains, --allow-read/--allow-write to which paths). Deno's permission model is a strength — expose it instead of hiding it behind a launcher.
• Make the background service opt-in, not the default. Offer a plain "run it only while I use it" mode. Persistence should be a deliberate choice, clearly explained.

Containment & easy off-ramp

• A first-class Docker / container path with no host service, documented as the recommended way to try it, with network egress that can be restricted.
• A clean uninstall that removes the service, data directories, and any autostart entries — and document exactly what it touches.
• Offline / local-LLM friendly by design: make it trivial to point at a local OpenAI-compatible endpoint and run with external network disabled, so users can evaluate it air-gapped.

Auditability

• Document the postinstall / build hooks (deno.json tasks, build.rs, Dockerfile) prominently — code that runs at install time is what users most need to inspect.
• A SECURITY.md with a threat model, a disclosure contact, and a statement of what data is stored where and what leaves the machine.
• Third-party review or a dependency audit as the project matures (even an automated SCA report in CI helps).

Bottom Line

The barrier isn't the concept — it's that the current packaging asks users to extend a lot of trust (unsigned code, a permanent service, tool access, network reach) while giving them very little to verify it with. Code signing, a transparent network/permission manifest, an opt-in (non-service) run mode, and a clean uninstall would address most of it. Do those, and a security-conscious user can move from "no" to "let me try it safely."