Installation

curiosity-cli comes in two forms. They are the same tool with the same commands and flags — pick whichever fits the machine:

Use the standalone executable when you want a real binary at a path you choose: a Windows service pointed at an .exe, a scheduled task that runs under a service account, an air-gapped or locked-down host, or any machine where installing the .NET SDK is not an option. Use the dotnet tool for developer machines and CI, where the SDK is already there and dotnet tool update is the easiest way to stay current.

Standalone executable (Windows)

Download curiosity-cli.exe from the releases page:

github.com/curiosity-ai/curiosity-cli/releases

Each release publishes a single self-contained curiosity-cli.exe. There is nothing to install — put the file where you want it and run it:

curiosity-cli.exe --help

It carries its own .NET runtime, so it runs on a machine with no .NET SDK and no .NET runtime installed.

To update, download the executable from the newer release and replace the old file. Release tags follow the workspace version scheme (v26.9.5197), so you can match the CLI to the workspace version you run.

Install as a dotnet tool

The NuGet package targets .NET 10, so install the .NET 10 SDK (or a compatible runtime) first.

dotnet tool install Curiosity.CLI --global

The tool installs as the binary curiosity-cli on your PATH (under ~/.dotnet/tools/ on Linux/macOS, %USERPROFILE%\.dotnet\tools\ on Windows). If your shell can't find it, add that directory to PATH.

Verify the install:

curiosity-cli --help

You should see the full list of commands — the same set documented under Commands.

Update the dotnet tool

dotnet tool update Curiosity.CLI --global

Keep the CLI roughly in step with your workspace version. Many commands use the Curiosity.Library client under the hood, so a very old CLI can lose features (or stop talking to a much newer workspace).

Uninstall the dotnet tool

dotnet tool uninstall Curiosity.CLI --global

For the standalone executable, delete the file.

Local (per-project) install

For CI/CD or repo-local pinning, install the tool into a local manifest instead of the global cache:

dotnet new tool-manifest        # creates .config/dotnet-tools.json
dotnet tool install Curiosity.CLI

Afterwards invoke the tool with dotnet tool run curiosity-cli ... or, after dotnet tool restore, simply curiosity-cli ... from within the repo.

Use from CI

GitHub Actions, GitLab CI, Azure Pipelines — any CI that has the .NET SDK can install the tool the same way. Typical sequence:

dotnet tool install Curiosity.CLI --global
export PATH="$PATH:$HOME/.dotnet/tools"
curiosity-cli wait-for -s "$WORKSPACE_URL" --max-timeout 600
curiosity-cli test     -s "$WORKSPACE_URL" -t "$CURIOSITY_TOKEN"

See wait-for for the readiness probe used above.

On a Windows runner without the .NET SDK, download the executable from the releases page instead and invoke it by path.

Running under a service account

A dotnet-tool install is scoped to a profile and runs through dotnet, which makes it a poor fit for anything Windows starts on your behalf:

• dotnet tool install --global installs into %USERPROFILE%\.dotnet\tools, which a service account or a scheduled task running as another user cannot read.
• The command it installs is a launcher that executes Curiosity.CLI.dll with dotnet, so the process Windows actually runs is dotnet.exe. A service supervisor pointed at an .exe, or a script that looks the tool up with tasklist / stops it with taskkill /im curiosity-cli.exe, does not see what it expects.

For those cases download curiosity-cli.exe from the releases page into a fixed, space-free path that every account can read. Scheduled share sync and monitor-with-permissions both build on that layout.

Where to get a Library Token

Most commands need a Library Token. Create one in your workspace under Manage → Tokens → Library.

• The token grants the same permissions as the user who created it.
• For CI use, create a dedicated service user with the minimum role required by the commands you intend to run (for example, the upload-front-end command needs Admin rights to manage interfaces).
• For local development, you can store the token encrypted on disk with store-token and then pass --token auto to other commands.

For JWT-style tokens used to call custom endpoints (a different concept), see Endpoint Tokens.

Source

The CLI is part of the open-source-friendly portion of the Curiosity codebase — its commands live under Library/Curiosity.CLI/ in the workspace repository. Each command has its own Program.<Command>.cs file. If you need a flag that isn't covered here, search the source for the command method (for example UploadFolder for upload-folder) and check the parameter list.