The MemoryRouter CLI: Upload a Reviewed File, Then Verify Recall

The knowledge worth keeping usually starts as files on a disk: reference docs, project notes, an export you have already reviewed. The MemoryRouter CLI is the part of the product built for that material. You decide what should be stored, upload it from the terminal, and the original stays where it is.

What the CLI does and does not do

The package is @memoryrouter/cli, and the executable it installs is memoryrouter. It uploads the files you point it at into a MemoryRouter vault and reports vault status. Official ChatGPT archives go through a separate importer with a review-and-approve step. The CLI runs on its own: no agent framework and no running model are required, because it is not an agent.

The part to see early is that the CLI covers one half of the job. It does not capture conversations, and it does not search the vault. Retrieval happens in whatever client you connect to that vault, which is why this post ends with a fresh conversation rather than a status line.

Install once, then authenticate

The package supports Node 20.16 and later on the 20 branch, plus 22.3 and up. Node 21 sits outside the supported range.

npm install --global @memoryrouter/cli
memoryrouter --version

Without a global install, npx @memoryrouter/cli works the same way. The full command reference lives in the CLI docs.

Create a Memory Key in the dashboard, pass it through your normal secret handling, and authenticate:

memoryrouter auth "$MEMORYROUTER_KEY"
memoryrouter whoami
memoryrouter status

The key lands in ~/.memoryrouter/config.json. That file is a secret now: keep it out of version control and out of any shared backup, and on macOS or Linux restrict it with chmod 600 on the file and chmod 700 on the directory. One behavior to plan around: auth still saves the key when the validation call cannot get through. status and the first upload result are the confirmation that setup worked, not the message auth printed. whoami prints the endpoint plus a partially masked key. It is a display command, not a validation.

Review the folder before it goes up

Directory upload is recursive, and it does not honor .gitignore. Nothing is excluded for you: not .git, not node_modules, not hidden directories, not credential files or private source. Set aside a dedicated folder that holds only the files you mean to store, and point the command at that folder. Do not aim it at a home directory or a repository you have not swept.

Inside that folder, the CLI handles markdown, text, PDF, DOCX, common source and configuration formats, and data files such as CSV. Two details matter before you rely on it. PDFs and DOCX files get converted to text, which is not OCR, so a scanned page can come out empty. And directory discovery has limits of its own: a file with under 50 characters of trimmed text gets skipped, and anything at 10,000,000 bytes or above is left out.

Session scoping deserves a sentence here. Adding --session my-project sends the upload under an X-Session-ID, which namespaces the data so a retrieval client can scope to the same stream. It is a label, not an access-control boundary, and it does not hide anything from the vault.

What a finished upload reports

Each batch reports the items stored and the items that failed. Read both. The CLI already retries transient network failures, rate limits, and server errors up to five times, and a clean exit after that does not mean every item landed. Resolve what failed before you repeat a large upload. The generic upload does not carry the approval manifest or the exactly-once receipt that the ChatGPT archive importer provides, so repeating it is worth avoiding until you know why it failed.

status is a vault diagnostic: item counts and usage. It cannot confirm that a given fact will be recalled in a given client. That takes a different check.

One fixture, then one fresh conversation

The setup is not done when the upload finishes. It is done when a fresh conversation reads back a fact you never typed into it. Make the first attempt synthetic so nothing real depends on it:

mkdir -p mr-cli-demo
printf '%s\n' 'For the upload rehearsal, the project label is garnet-fathom-58.' > mr-cli-demo/rehearsal.md
memoryrouter upload ./mr-cli-demo/rehearsal.md

Confirm the result shows a stored count and no failures, then close the terminal. Open a new conversation in one of the supported integrations pointed at that vault. Ask for the project label from memory, without supplying it. If garnet-fathom-58 comes back, the path from disk to recall works end to end. If it does not, confirm the client is reading the right vault and session scope, and look at the tool result itself before concluding anything. A fluent answer with no memory result behind it is not evidence.

Where the boundary sits

Uploaded files leave the machine. They are stored by the hosted service, so treat the command as a decision about the material itself, not a convenience toggle. If the files have to stay on local hardware, a local archive remains the right answer and this is not the route.

Removal has two pieces of its own. Uninstalling the package leaves stored memories and the config file in place. Clearing a disposable test vault is what delete is for, and it asks for an interactive confirmation first. To cut local access, delete the config file and revoke that key from the dashboard. And the vault does not track your source folders: editing a file after upload does not update or remove the stored copy.

The first run takes about a minute. Create your MemoryRouter account and take one reviewed file from the terminal to a fresh conversation before anything real goes up.