Memories

Memories / Documentation

On this page

Desktop tray and WebUI

The Windows tray and macOS menu-bar app provide a quick view of the local Memories daemon. They share an embedded status dashboard and restricted ordinary-card editor with no external fonts, scripts or analytics. The dashboard supports English, Chinese, Japanese, German and French and adapts to narrow windows.

The status projection remains read-only. When unlocked, the card editor accepts a vault ID and provides a type picker, typed fields, renaming/removal and drag reordering, plus reusable template creation. Its authenticated, origin-checked POST /api/cards forwards only an deliberate card/type allowlist through the sibling CLI. It cannot unlock, elevate, run programs or reveal sensitive values. Native mobile/CLI verification is required for sensitive operations; there is no browser biometric/PIN enrollment. See card types.

Start

  • Windows: extract the release ZIP and double-click memories-tray.exe. Keep it beside memories.exe. The launcher does not open a console window.
  • macOS: open Memories.app from the macOS package. It appears in the menu bar, without a Dock window. The application bundle includes its companion CLI.
  • From a terminal: memories tray opens the native tray and dashboard; memories webui opens only the browser dashboard and stays in the foreground. Linux can use webui; native tray support is limited to Windows and macOS.
memories --home /path/to/development-home tray
memories --home /path/to/development-home webui --no-open --port 0
memories-tray --home /path/to/development-home --no-open

--home / MEMORIES_HOME uses the same store as the CLI. Without an override, the launcher uses storage_dir from the selected configuration or the normal per-user Memories home. --config PATH / MEMORIES_CONFIG selects a TOML file; see configuration. --port 0 (the default) chooses a free loopback port; a specified port must also be free. The foreground webui command prints its local capability URL, including a fragment token. --no-open suppresses automatic browser opening. The tray's Open status dashboard menu item can open it later, including when desktop.open_browser = false in the configuration; --open deliberately overrides that setting. --lang selects the tray language; the browser initially follows its own locale and has a language selector.

Status and service lifecycle

The tray menu reports offline, setup-required, locked or unlocked. Start daemon launches the companion CLI daemon when it is unavailable. It does not initialize storage, unlock it, or request elevation. Use memories init, memories unlock and memories sudo in a terminal as usual.

The page refreshes every two seconds. When unlocked it shows library, active proxy and remote-session counts; configured cloud provider kinds; pending upload and download counts; applied/rejected transfers; and libraries awaiting sync. The status projection does not show memory text, library names, credentials, account identities, file paths or tokens. Library/sync details are cleared when the daemon locks or becomes unavailable. Status polling does not keep the vault unlocked.

Recent changes are observations made while the current browser page is open, not the persistent security audit log. An offline status can mean the daemon is stopped, busy for more than the probe deadline, or incompatible. Upgrade the CLI and daemon together, then restart the daemon after upgrading.

Quit tray removes the icon and stops that dashboard listener. It leaves the daemon running, including a daemon started from the menu. For foreground WebUI, Ctrl+C closes its listener. No automatic login-start registration is installed. Separate launches use separate ports and tokens. To reopen a dashboard after a restart, use the tray menu instead of an old bookmarked URL.

Browser access boundary

The dashboard is bound to 127.0.0.1 only and is intended for the same computer. Each launch uses a new random access token. The browser strips it from the address bar and stores it only for the tab session. Status requests need that token and pass Host/Origin checks. The ordinary-card editor uses the same checks and a closed operation allowlist; there are no HTTP unlock, elevation, credential delivery, command-execution or generic IPC endpoints. The launch JSON reports read_only: false, status_read_only: true and card_editor: true to distinguish card writes from the read-only status projection. See security.

Build and package

cargo build --workspace --release --locked builds memories-tray alongside the CLI, relay and FFI. Windows packages are created from a clean committed checkout:

pwsh -File scripts/package-windows.ps1

On a macOS host with Rust, Xcode Command Line Tools and Python 3:

bash scripts/package-macos.sh

The macOS script builds the host architecture (Apple Silicon or Intel), packages Memories.app, CLI/relay/FFI files, all tracked docs/, font licenses, a per-file build manifest and archive checksum. It does not sign or notarize the app for distribution. Windows builds do not validate macOS runtime behavior. Consult validation for what was actually exercised for each release.

On a Linux GNU host, bash scripts/build-linux.sh builds the release workspace; bash scripts/package-linux.sh creates a CLI/relay/FFI .tar.gz from a clean committed checkout. See the Linux prerequisites. Use memories webui for the dashboard; the Linux package omits the unsupported native tray launcher.