Loss of persistent "brain" causes Zero to forget its own identity, drop MCP connections, and touch other agents' config

[PatrickNoFilter]

Loss of persistent "brain" causes Zero to forget its own identity, drop MCP connections, and touch other agents' config

Summary

Zero currently has no persistent memory/brain across restarts. This produces a
cluster of related failures that all stem from the same root cause: there is no
long-lived state that survives a session restart. They should be treated as one
issue, not three separate ones.

Environment note: this was observed and reproduced on Android / Termux
(/data/data/com.termux/files/home, shell /bin/sh). On mobile/Termux the lack of
a persistent brain is especially painful because the agent cold-boots with no
record of its own identity or verified MCP state, and the surrounding OS/config
layout differs from a desktop Linux/macOS install. Any brain/memory solution must
work first-class on Termux (local, offline, no external service required).

Symptoms observed (single root cause)

1. Forgets its own identity after restart.
   After a restart, Zero referred to itself as "OpenClaude" and described itself
   as coming from a different project, even though it is Zero
   (Gitlawb/zero). It had no persistent record of what it is.

2. MCP connections are not reliably re-established / remembered.
   MCP servers registered in ~/.config/zero/config.json (e.g. as_brain,
   continuum, eling) were assumed "dead" after a restart simply because the
   agent had no memory of having verified them. The servers were actually fine;
   the agent lost track of their state. An unconfigured optional server
   (e.g. firecrawl with no API key) also emits a loud 401 on every startup.

3. Touches other agents' config files.
   Because it forgot its identity and where its own config lives, the agent
   edited ~/.openclaude.json (a different application's config) instead of
   ~/.config/zero/config.json. Without a persistent brain, the agent cannot
   reliably distinguish "this is my config" from "this belongs to another tool."

Root cause

Zero has no durable brain/memory layer that persists across runs. Every restart
is effectively an amnesiac cold boot: identity, verified MCP state, and
config-file ownership all have to be re-derived from scratch, and when that
re-derivation is imperfect the agent misidentifies itself and other tools' state.

Proposed direction

• Give Zero a persistent brain (local, offline-first) that survives restarts
  and records at minimum:
  • Its own identity/role (Zero, repo Gitlawb/zero).
  • Verified MCP server connection state (so it doesn't re-diagnose healthy
    servers as broken).
  • Ownership/trust boundary of config files (never edit another agent's config
    unless explicitly told).
• The brain must work on Android / Termux (local filesystem under
  /data/data/com.termux/files/home), not depend on a desktop-only path or an
  external cloud service.
• Harden MCP startup so unconfigured optional servers fail silently / are
  clearly marked optional instead of printing 401 noise on every launch.
• On startup, load the persistent brain before any config-editing or
  identity-sensitive action.

Related (but distinct) existing issues

• zero upgrade fails on Android/Termux: "unsupported release platform: android" #598 — zero upgrade / update --check fails on Android/Termux
  (unsupported release platform: android); PR fix(update): clearer error on unsupported release platform (android/termux) #603 open. Same Termux environment,
  different symptom.
• fix(tui): Termux context-menu paste injects characters one at a time, breaking multiline input #583 — Termux context-menu paste injects characters one at a time (multiline
  input broken). Same Termux environment.
• Android/Termux: add os: android to package.json — linux-arm64 binary works on Termux #449 — add os: android to package.json so linux-arm64 binary works on Termux
  (closed/fixed).
• Unconfigured optional MCP server (firecrawl) prints HTTP 401 warning on every startup #552 — unconfigured optional MCP server (firecrawl) prints HTTP 401 on startup
  (closed/fixed by fix(mcp): silence startup warning for unconfigured default servers #563). Same surface symptom, different framing.
• Custom configured local provider is not persistent across runs #555 — custom provider/config not persistent across runs (closed/fixed).
• mcp: project config can re-enable user-disabled MCP servers #512 / Harden project-scoped MCP credential boundaries #596 / security: untrusted workspace .zero/ hooks, plugins, and MCP servers run code without a trust prompt #540 — MCP config trust-boundary & credential isolation (project
  vs user config).

This issue is the unifying one: those are symptoms of the missing persistent
brain (made worse on Android/Termux).

[PierrunoYT]

Checking now

[PierrunoYT]

Dug into this against current main. Findings, per symptom:

1. Identity confusion ("OpenClaude") - not reproducible against the code. system_prompt.md (embedded via go:embed) hardcodes "You are Zero, an autonomous terminal coding agent" and is re-injected fresh on every single run - there's no code path where identity is loaded from mutable/persisted state, so there's nothing to "forget" between restarts. A repo-wide search for "OpenClaude" returns zero hits. This looks like model-level output drift, not something a persisted identity file would fix (the system prompt already asserts identity every turn).

2. MCP "dead after restart" / 401 noise - already fixed upstream. The unconfigured-default-server warning suppression (e.g. firecrawl with no API key) landed via #563 (commit 302f58b), with regression coverage in internal/cli/app_test.go and internal/mcp/registry_test.go. What is still true: there's no cross-run cache of "this server verified reachable last time" - every launch re-connects fresh (internal/mcp/registry.go), so a transient failure looks identical to "always dead." That part is a real, narrow gap.

3. Touching ~/.openclaude.json - not reproducible. Config path resolution (internal/config/paths.go) is fully deterministic, always <UserConfigDir>/zero/config.json. There's no scanning/guessing of candidate config paths anywhere in the codebase, so there's no mechanism by which Zero could target a different tool's config file.

Proposal: rather than a general-purpose "persistent brain," split out the one concrete, scoped piece that's real: an MCP connection-health cache (e.g. ~/.config/zero/mcp-health-cache.json) recording last-known-good connect state per server, keyed by the existing stable Server.Identity hash, mirroring the atomic-write pattern already used by internal/mcp/permissions.go's PermissionStore. This is Termux-compatible for free since UserConfigDir() already resolves correctly there with no platform-specific code needed.

Happy to send a PR for just that piece. The identity and config-ownership symptoms don't have a corresponding bug in the current code, so I'd suggest closing or re-filing those with concrete repro steps if they're still occurring.

[PatrickNoFilter]

Thanks for digging into this, @PierrunoYT — that matches what we found on our end too.

On the identity / config-ownership symptoms: fair enough. You are right that system_prompt.md re-asserts identity every run and paths.go is deterministic, so there is no code path that forgets identity or points at ~/.openclaude.json. The "OpenClaude" slip and the wrong-file edit were almost certainly model-level drift plus a noisy/confusing prior session, not a Zero bug. I won't block this issue on those two — happy to drop them.

On the one real gap (no cross-run MCP health cache): agreed, and this is exactly the pain we hit. Our workaround has been to bolt on a persistent brain outside Zero via an MCP server (as_brain, an eling-backed local fact store at ELING_HOME=~/.eling). It persists identity / verified-MCP-state facts across restarts and auto-connects from ~/.config/zero/config.json, so the agent no longer re-diagnoses healthy servers as "dead" after a cold boot. It works today on Android/Termux (offline, no desktop-only deps). It's a stopgap, not a core fix: it lives in a separate process and isn't part of Zero itself.

Your scoped proposal is the right place for a first-class fix: a ~/.config/zero/mcp-health-cache.json recording last-known-good connect state per server, keyed by the stable Server.Identity hash, reusing the atomic-write pattern from permissions.go. That closes the genuinely real gap (a transient failure looking identical to "always dead") and is Termux-compatible for free.

Request: please go ahead and send that PR for the MCP health-cache piece. We'll keep as_brain as our local crutch until something lands in core, and I'll trim the issue down to just the health-cache scope (the rest is model drift / not-a-bug). Thanks for offering to take it on.

[PatrickNoFilter]

One important caveat from our own testing (to keep the issue accurate):

We verified the as_brain MCP server reconnects and reads its DB after a cold restart — killing the process and re-launching it exactly as Zero does (python3 -m eling.as_brain.mcp_server) returns all 20 as_brain tools and brain_recall reads the persisted facts.db/kb.db correctly. So the brain survives restart.

However, this only proves the server auto-reconnects and is queryable. It does not prove Zero automatically queries the brain at startup. There is no auto-recall hook in system_prompt.md, and the maintainer confirmed identity is go:embed'd and re-injected every run. So our brain is consulted on-demand, not auto-loaded at boot.

In other words: the data persists and the connection auto-recovers, but there is no automatic load of brain contents into the prompt at startup. True "auto-load identity / memory at boot" would still require either:

• a Zero feature (e.g. an auto-recall step in system_prompt.md or a startup hook that queries brain_recall), or
• a user-side startup hook that injects a recall summary before each session.

So the persistent-brain problem is partially solved by the MCP approach (storage + auto-reconnect work), but the auto-load at boot gap remains a legitimate feature request. Flagging it so the issue scope is precise. The as_brain workaround covers persistence + reconnect today; the missing piece is automatic injection into the system prompt on startup.

[Vasanthdev2004]

Looked into this against current main — agreeing with @PierrunoYT and adding what I verified myself:

Identity slip — not reproducible. internal/agent/system_prompt.md is embedded into the binary and re-injected as the system prompt on every run, opening "You are Zero, an autonomous terminal coding agent." There's no mutable identity to forget between restarts, and the other tool's name appears nowhere in the source. Reads as model output drift in an environment where that tool happened to be installed, not a Zero bug.

Editing a different tool's config file — not reproducible either. internal/config/paths.go resolves the user config to a single deterministic path, <UserConfigDir>/zero/config.json, with no scanning or candidate-listing anywhere. Zero has no code path that would target another app's config; whatever wrote to that file, it wasn't Zero's config layer.

MCP "dead after restart" — the firecrawl 401 noise is already handled (ships as a keyless UnconfiguredDefault and is skipped at startup, with regression tests). The one genuine gap is that there's no cross-run "verified-reachable" cache, so a transient startup failure looks identical to "always dead" — the servers aren't actually broken, they just get re-diagnosed from scratch each boot. @PierrunoYT's scoped proposal (~/.config/zero/mcp-health-cache.json keyed by Server.Identity, atomic-write like permissions.go) is the right first-class fix for that and is Termux-compatible for free.

Net: I'd scope this issue down to the MCP health-cache and drop the identity/config-ownership symptoms as model drift, not Zero. Happy for the health-cache PR to go ahead under this issue.

[eli-l]

Zero is CLI coding tool, not an entire agentic setup.
Repeatable flow context may become specialists - injecting specific prompt and giving advanced personality/goals.
Persistent memory can be achieved with existing plugin system, that could inject preserved state on session start and save updates on session end.

[anandh8x]

The original reported issues have already been investigated in this thread and are either not reproducible or already fixed. Closing this broad report for now.