`store-token`

Encrypts a Library Token and saves it locally, keyed by workspace URL. After running this, you can pass --token auto to any other command — the CLI will look up the matching entry, decrypt it, and use it for that call.

Syntax

Usage: curiosity-cli store-token --server <url> --token <token>

curiosity-cli store-token \
  --server https://my-workspace.example.com/ \
  --token  $CURIOSITY_TOKEN

Then, on subsequent commands:

curiosity-cli test           -s https://my-workspace.example.com/ -t auto
curiosity-cli upload-folder  -s https://my-workspace.example.com/ -t auto -p ./docs

Options

Option	Description
`--server`	Workspace URL. The same URL must be passed when reading the token. Alias `-s`.
`--token`	The plain-text Library Token to encrypt and store. Alias `-t`.

Where the token lives

The store is a per-user config file in the OS app-data directory:

Platform	Path
Linux	`~/.config/.mosaik.cli.config` (or `$XDG_CONFIG_HOME/.mosaik.cli.config`)
macOS	`~/Library/Application Support/mosaik.cli.config`
Windows	`%APPDATA%\.mosaik.cli.config`

Entries are indexed by a hash of the server URL and encrypted using the URL itself as the key derivation seed. The file is owned by the calling user — protect it the same way you would an SSH private key.

Updating or rotating

Re-running store-token for the same server URL replaces the existing entry. There is no separate remove command — to remove an entry, delete the config file or use dotnet user-secrets-style tooling to edit it.

Limitations

The store is per account, not per machine: the file lives in the calling user's app-data directory, and the key is derived from the server URL alone. So a second account on the same machine does not see it — and anyone who can read the file can decrypt it. What protects the token is the ACL on that directory; treat the file the way you would an SSH private key.
The same server URL maps to a single token. For multi-user / multi-tenant scenarios, switch to environment variables (-t "$CURIOSITY_TOKEN") per shell.

Remarks

Use store-token for local development so you can pass --token auto instead of repeating raw tokens on the command line.
The stored entry is keyed by server URL and readable by the account that wrote it; re-running for the same URL replaces the existing entry.
For CI or multi-tenant use, prefer per-shell environment variables over a stored token.

Storing a token for an account that cannot log on

A scheduled task or a service runs as an account nobody logs into interactively, and store-token writes into the profile of whichever account runs it. Register a throwaway task to run the command as that account once — Running a sync on a schedule does exactly this with .\curiosity-sync.ps1 store-token, and monitor-with-permissions shows the same trick for a gMSA running a service.

store-token