Curiosity CLI
The official command-line tool for Curiosity Studio. Test connections, upload front-ends, ingest folders, sync git trackers, and export/import workspace definitions from any shell or CI pipeline.
What is curiosity-cli?
curiosity-cli is available as a dotnet global tool (the NuGet package Curiosity.CLI) and as a standalone Windows executable on the releases page. It exposes every operation you would otherwise script against the Workspace's HTTP / Graph API, with consistent --server / --token arguments and kebab-case command names.
Looking for curio?
curio (Curiosity.Shell) is a different tool: it opens Sudo's sandbox from your terminal, for editing, building and approving workspace changes by hand or through a coding agent. curiosity-cli covers operations and CI: connection tests, ingestion, front-end uploads and definition promotion.
Use it to:
- Promote a custom front-end bundle between environments.
- Iterate on a custom front-end locally while talking to a remote workspace.
- Ingest files (folders, PSTs) into a workspace, with or without Active Directory ACLs.
- Export and import custom code (endpoints, indexes, scheduled tasks) between workspaces — the foundation of GitOps-style workspace deployments.
- Wait for a workspace to become ready, then run smoke tests, inside a CI/CD pipeline.
- Turn a local CSV or JSON file into a shareable copy with synthetic values.
- Download workspace audit log files into an archive, verify them against tampering, and convert them to CSV or JSON with user names and emails filled in.
Install
With the .NET 10 SDK on the machine:
dotnet tool install Curiosity.CLI --global
Or download a self-contained curiosity-cli.exe from GitHub Releases — no .NET install needed, which is the form to use for Windows services and scheduled tasks.
Then confirm:
curiosity-cli --help
Full instructions, update path, and which form to pick on Installation.
Common arguments
Almost every command takes the same two arguments — a workspace URL and a Library Token:
curiosity-cli <command> \
--server https://my-workspace.example.com/ \
--token $CURIOSITY_TOKEN
Short forms -s and -t work everywhere. Tokens can also be stored encrypted on disk with store-token so you can pass --token auto afterwards.
See Common Options for the full list (timeouts, mTLS, ignore-certificate-errors, environment variables, logging).
Commands
serve
Serve a locally built custom front-end and proxy API calls to a remote workspace. With --watch, compile it and reload on every change.
Scheduled sync
Windows: run the one-shot ingest on a Task Scheduler trigger instead of keeping a monitor running.
Where to go next
- Building a custom UI? Start with Custom Front-End development workflow — it uses
serveandupload-front-endend-to-end.serve --watchcompiles and reloads while you edit. - Ingesting an existing share or PST archive? See
inspectfirst, thenupload-folderoringest-pst. - Keeping a Windows network share in sync? Running a sync on a schedule is a worked Task Scheduler setup, and the reason to prefer it over a long-running monitor on a network drive.
- Moving custom code between dev, staging, and prod? See
export-workspace-definitionsandimport-workspace-definitions. - Keeping or reviewing audit trails? See Audit logs, then
download-audit-logs,verify-audit-logandconvert-audit-log. - Need to wait for the workspace before running smoke tests in CI? See
wait-forand Workspace deployment operations.