Other Commands

A grab-bag of utility commands that don’t fit the main resource families.

apiAuthenticated requests to any Redmine endpoint.

categoriesList issue categories for a project.

trackersList all available trackers.

statusesList all issue statuses.

custom-fieldsDiscover admin custom field definitions.

completionGenerate shell completion scripts.

updateSelf-update the binary.

api

Make authenticated requests to any Redmine REST API endpoint.

GET

redmine api /users/current.json

redmine api /issues.json -f project_id=myproject -f limit=5

POST

# Method auto-detected when body fields are supplied
redmine api /issues.json \
  -F 'issue={"subject":"Bug report","project_id":1}'

From file

# - reads from stdin
redmine api /issues.json --input body.json

Filter with --jq

# --jq runs against the response body
redmine api /issues.json -f project_id=myproject --jq '.issues[].subject'
redmine api /users/current.json --jq '.user.login'

Explicit method

redmine api -X DELETE /issues/123.json
redmine api -X PUT /issues/123.json -F 'issue={"status_id":5}' --silent

Flag	Description
-X, --method	HTTP method (default: GET, or POST when a body is provided)
-f, --field	Query parameter as key=value (repeatable)
-F, --raw-field	JSON body field as key=value (repeatable)
--input	Read request body from file (- for stdin)
-i, --include	Show response status line and headers
--silent	Suppress response output

-F sets top-level keys

Each -F key=value becomes a top-level key of the JSON body. Numbers, booleans, arrays and objects are sent as JSON, anything else (including invalid JSON) as a string. A value that looks like a number is sent as one, so -F 'name=1.10' sends 1.1. Put such strings inside a JSON object: -F 'version={"name":"1.10"}'. Bracket notation is not expanded: -F 'issue[subject]=Bug' sends a key literally named issue[subject], which Redmine ignores. A PUT like that still succeeds, but changes nothing. Pass nested objects as a JSON value (-F 'issue={"subject":"Bug"}') or send the whole body with --input.

Tip

JSON responses are pretty-printed when stdout is a terminal. 4xx and 5xx responses still print the body but exit with code 1. In JSON mode (-o json or --jq) without -i, such a response is reported as the JSON error envelope on stderr instead, and stdout stays empty.

categories

redmine categories list --project <identifier>

Lists issue categories for a project.

trackers

redmine trackers list
redmine trackers get Bug

Lists all available trackers. The list view includes the default status for each tracker, and trackers get shows richer metadata such as enabled standard fields when the Redmine server exposes them.

statuses

redmine statuses list

Lists all issue statuses.

custom-fields

redmine custom-fields list
redmine custom-fields get "Severity"
redmine custom-fields get 7 --output json

Lists or inspects custom field definitions. The list view surfaces target resource type, field format, and the required/filter/searchable/multiple flags. custom-fields get adds the default value, length and regexp constraints, possible values for list fields, plus the trackers and roles a field is restricted to.

Caution

The underlying GET /custom_fields.json endpoint is admin-only - the command returns 403 Forbidden for non-admin API keys.

Note

Redmine 7.0 extended this endpoint, and custom-fields get surfaces the additions in its table output:

• For All Projects and Projects describe a field’s project scope. Redmine only reports project scope for issue custom fields, so these never appear for a time entry, project or version field.
• Roles is now reported for time entry, project and version fields too, where older servers reported it for issue fields only.
• Default Mode appears on date-format fields whose default is relative (for example days_after_today).

The For All Projects row is omitted entirely when the server does not report the flag, rather than shown as no, so its absence means “not reported” and never “restricted”. A missing Projects row is different: it means the field is not scoped to specific projects, which for an issue field usually means it applies to all of them.

Shell completion

bash

redmine completion bash > /etc/bash_completion.d/redmine

zsh

redmine completion zsh > "${fpath[1]}/_redmine"

fish

redmine completion fish > ~/.config/fish/completions/redmine.fish

Note

Homebrew installs ship completions automatically — run the command above only if you installed via the script, go install, or manual download.

Completion candidates such as tracker, version, category and member names come from the server. The bash script quotes them before bash sees them, so a name like $(cmd) is offered as text and never run; candidates containing line breaks are dropped and control characters are neutralized. Bash scripts generated by older versions passed candidates to bash unquoted: if you saved the output of redmine completion bash to a file, regenerate it after upgrading.

Completion honors the global flags already on the command line, so redmine --profile work issues list --project <TAB> (likewise --config, --server, --api-key-file) completes against that profile or server. With --api-key-file -, completions that need the server are skipped instead of reading the key from the terminal.

self-update

checksum verified attestation verified

redmine update

Checks GitHub for the latest release, downloads it, and replaces the current binary only after two checks pass:

1. Checksum — the archive’s SHA256 must match the release’s checksums file.
2. Attestation — the archive’s SHA256 must have a GitHub artifact attestation (SLSA build provenance, signed through Sigstore and recorded in its transparency log) issued by this repository’s release.yml workflow for exactly the release tag being installed.

Besides the repository, the built-in check pins the signer workflow and the source ref, so it is stricter than gh attestation verify --repo aarondpn/redmine-cli alone. The equivalent gh command is below (Windows archives end in .zip). install.sh runs it when a recent gh is installed and logged in; otherwise the script installs after the checksum check only and prints the command so you can run it yourself (see Installation):

gh attestation verify redmine-cli-<os>-<arch>.tar.gz --repo aarondpn/redmine-cli \
  --signer-workflow aarondpn/redmine-cli/.github/workflows/release.yml \
  --source-ref refs/tags/<tag>

The checksums come from the same place as the archive, so only the attestation proves the binary was built by the project’s release pipeline. The update is refused if the attestation is missing, invalid, or signed by any other identity. A release is attested a few minutes after it is published; if you update within the first 30 minutes and its attestation is not there yet, redmine update says so and asks you to try again shortly instead of reporting a failed verification.

When installed via Homebrew, delegates to brew upgrade.

Flag	Description
--skip-attestation	Install with checksum verification only. Prints a warning.

Verification needs to reach api.github.com (attestations API) and tuf-repo-cdn.sigstore.dev (Sigstore trusted root, cached for a day under your user cache directory). If either is unreachable, redmine update refuses to install and suggests --skip-attestation. Set GITHUB_TOKEN or GH_TOKEN to avoid GitHub API rate limits; it is only sent to api.github.com.

Do not skip verification on failure

--skip-attestation is meant for networks that block the verification endpoints. If verification fails (rather than being unreachable), do not work around it; report it as a security issue. The same applies to REDMINE_CLI_SKIP_ATTESTATION=1, the install script’s equivalent.

If the binary’s directory is not writable, the error suggests reinstalling with the install.sh from the same release tag rather than from main.

Startup update check

On every invocation, redmine checks GitHub for a newer release in the background. When one is available, a notice is printed to stderr after the command output:

A new version of redmine is available: v1.2.0 → v1.3.0
https://github.com/aarondpn/redmine-cli/releases/tag/v1.3.0
Run "redmine update" to upgrade

The check starts in the background together with the command and gives up 2 seconds after startup. Its result is only printed after a command that succeeded; a failed command exits right away. If the check is still running when the command finishes, the CLI waits for it, at most until that 2-second deadline, and prints Checking for updates... to stderr once the wait exceeds 200 ms. A fresh cached result (see below) answers immediately, so the delay only happens when GitHub has to be asked: once a day after a successful check, but on every run while checks fail or time out (failures are not cached). It is automatically skipped when:

• the command is redmine update itself;
• stderr is not a TTY (piped output, CI);
• REDMINE_NO_UPDATE_CHECK is 1 or true.

The result is cached for 24 hours in ~/.redmine-cli-update-check.json (readable only by you). A cache entry whose release URL is not a release page under https://github.com/aarondpn/redmine-cli/releases/tag/ is ignored, so a tampered cache cannot inject a link into the notice.

To disable permanently:

export REDMINE_NO_UPDATE_CHECK=1