Skip to content
eternego / docs

Workspace, diary, logs

Three more places hold a persona's working files, her portable backup, and the daemon's record of what happened. None of them is part of her identity — but the diary is the one thing you can't lose if you ever want to move her.

workspace/

~/.eternego/personas/<id>/workspace/ is her sketchpad — a directory she reads and writes freely. Drafts, scripts, downloaded data, files she's working on: anything she's actively building goes here. It is the one place under her control where she creates and edits at will, the counterpart to her read-only home/.

There is no fixed structure. She organizes it however the work needs — a common pattern is a dated folder per task:

workspace/
└── research/
    └── eternego-public-surfaces-2026-06-03/
        └── findings.md

Her permissions grant her free access to this path, and her instructions often tell her to save work-in-progress here so a later session can continue from evidence on disk rather than from memory. Her live context frequently points back into the workspace ("resume from workspace/research/.../findings.md") — the workspace is durable, her active memory is not.

Nothing here is consolidated, summarized, or read into her identity. It is exactly what it looks like: her files. Browse or edit them like any other folder.

The workspace is not in the diary

The nightly diary backs up home/ only — workspace/ is left out. Her in-progress files do not travel with her when you migrate her to another machine. If something in the workspace matters long-term, have her fold the result into home/ (e.g. record the conclusion so it consolidates into her memory) or back the workspace up yourself.

diary/

~/.eternego/diary/<id>/<id>.diary is the encrypted nightly backup of her entire home/. It is the single thing needed to move her to another machine — restore the diary elsewhere and she continues as herself. (It backs up home/ only; her workspace/ is not included — see the warning above.)

~/.eternego/diary/
└── 6c17c83c-3158-450d-8e43-0e7efea717c1/
    └── 6c17c83c-3158-450d-8e43-0e7efea717c1.diary

It is written when she sleeps (her nightly ritual, or POST /api/persona/{id}/sleep) and once at creation. The flow:

  1. Her home/ is zipped into an archive.
  2. The archive is encrypted with a key derived from her recovery phrase (the 24 words) and her persona id.
  3. The encrypted bytes are written to <id>.diary.

The file is a Fernet token — an opaque, URL-safe base64 blob beginning gAAAAA…. It is unreadable without the key; you can't open it in an editor and see her files.

The recovery phrase

The encryption key is derived from a 24-word recovery phrase (BIP-39 words) generated once when she's created and shown to you once, at that moment. It is also stored in your operating system's secure keyring (Keychain on macOS, Credential Manager on Windows, Secret Service / keyring on Linux), which is how the running daemon can write and read her diary automatically without prompting you.

  • On this machine, the keyring holds the phrase, so backup and restore are automatic.
  • To move her to another machine, you need the 24 words themselves — the new machine's keyring doesn't have them. This is the only path to migration. Save the phrase when it's shown. Lose it and she still runs here forever, but can never be migrated.

Because the key is the phrase, a diary on its own is useless to anyone who doesn't have the words — the backup is safe to copy around. Restoring is the reverse of the flow above: decrypt with the phrase, unzip, and copy the contents back into personas/<id>/home/. The Create & migrate API drives this.

logs/

The daemon's operational logs — daily text files. Where they live depends on how she's running: a packaged app (.dmg/.exe/.AppImage) or installed service writes to ~/.eternego/logs/; a bare source clone writes to ./logs/ (or wherever LOGS_DIR in .env points — the installer scripts set it to ~/.eternego/logs/).

~/.eternego/logs/                          # (or ./logs/ for a source clone)
├── eternego-2026-05-22.log                # the daemon's narrative, all personas
├── eternego-signals-2026-05-22.log        # the raw signal stream, all personas
└── eternego-<persona-id>-2026-05-22.log   # per-persona, debug mode only
  • eternego-<YYYY-MM-DD>.log — the running daemon's text log for that day, shared across all personas: the cognitive-cycle stages firing (realize, recognize, learn, decide, reflect, consolidate, archive), tool and ability calls, model requests, and errors. This is where you look when you want to see what she actually did, or why something went wrong.
  • eternego-signals-<YYYY-MM-DD>.log — the day's raw signal stream (the bus), also whole-system.
  • eternego-<persona-id>-<YYYY-MM-DD>.log — written only in debug mode (--debug), splitting one persona's traffic into its own file.

Secrets are masked in the log output. These logs are distinct from health.jsonl, the per-persona, machine-readable heartbeat record — the logs/ files are the human-readable narrative. They are not encrypted and not backed up in the diary — they're operational, not part of her identity.

Different entry point, same place

However the daemon runs — the desktop app, the installed service, or eternego daemon — it writes to the same log directory for that install: ~/.eternego/logs/ for a packaged or installed run, ./logs/ for a source clone. See Operating for reading and rotating them.