The Empirical CLI is becoming the front door
Installing Empirical should feel like choosing where you want memory to work, not like learning the internals of an integration stack.
The first experience with a memory tool should not be a scavenger hunt.
You should be able to say what you are using, sign in once, and understand what happens next. If you use Codex, Claude, and Copilot in the same week, the setup should still feel like one product rather than three unrelated rituals.
That is the direction of the Empirical CLI.
Install once, choose your surfaces
The CLI guide now describes the normal path in plain language: install the latest Empirical CLI, authenticate with OAuth when the CLI needs access, and choose which native plugins you want your agents to use.
The core memory plugin gives an agent the general Empirical guidance. Optional plugins add Work History, Scar Tissue, or Todo when those behaviors fit the way you work. The plugin guide explains the choices, and the individual package guides explain what each one adds.
You might install only the core plugin for a new personal project. Later, when a codebase starts accumulating decisions and hard-earned corrections, you can add Work History and Scar Tissue. When the project develops a real backlog, add Todo. The setup grows with the work instead of asking you to predict every future need on day one.
OAuth should feel ordinary
The CLI uses the normal authenticated OAuth path for commands that need your Empirical account. That keeps interactive use straightforward: sign in, run the command, and let the CLI manage its stored session.
Agent-facing MCP connections have their own authentication because each agent needs permission to use the memory server. The installation docs explain that distinction without asking you to understand token mechanics before you can get started.
Headless authentication still exists for automation and external runtimes. It is a deliberate path for machines that cannot open a browser, not a prerequisite for normal local CLI use.
Updates should not become a second installation
One of the more frustrating patterns in tool setup is learning that a new release exists, then having to remember a separate sequence of commands to make your local agent aware of it.
The CLI can now check the installed native Empirical plugin version and offer an update when a newer release is available. If you accept, it takes you back through the same plugin choices instead of silently changing behavior behind your back.
That matters because preferences are real. One person wants Work History enabled. Another wants only memory and Todo. A good update path preserves that choice while making the new version available.
The goal is not more commands. It is a calmer handoff between releases.
For the larger story behind receipts, portability, and making memory trustworthy, read Memory trust and portability are live. For the native packages themselves, visit the Empirical memory plugin repository.
If you are coming from an earlier setup, the older Claude web installation docs update is a useful reminder of why clear sequencing matters. The current docs also support copying or opening each page as Markdown, which makes them easier for agents and terminal workflows to consume.