> For the complete documentation index, see [llms.txt](https://docs.rumi.systems/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rumi.systems/rumi-cli/commands/set.md).

# set

The `rumi set` command views and changes Rumi CLI settings. Settings are per-user preferences about how the CLI itself behaves, and they persist across CLI upgrades.

## Usage

```bash
rumi set                      # list every setting and its current value
rumi set <setting> <value>    # change a setting
```

## Settings

| Setting      | Values        | Default | Description                                   |
| ------------ | ------------- | ------- | --------------------------------------------- |
| `stacktrace` | `on` \| `off` | `off`   | Print a Java stack trace when a command fails |

`on` and `off` are the documented spellings. `true`/`false`, `yes`/`no`, and `1`/`0` are accepted as synonyms and normalized to `on`/`off` when stored.

## Examples

List the current settings:

```bash
$ rumi set

      SETTING        VALUE    DEFAULT  DESCRIPTION
      stacktrace     off      off      Print a Java stack trace when a command fails

      settings file: /Users/you/.nvx/rumi-cli/settings.properties

      Run 'rumi set <setting> <value>' to change one.
```

Turn stack traces on:

```bash
$ rumi set stacktrace on
stacktrace = on
saved to /Users/you/.nvx/rumi-cli/settings.properties
```

## stacktrace

By default, a failing command prints only its message:

```bash
$ rumi dev entity remove processor -n Address -a /path/to/app

**** cannot remove entity 'Address': still referenced by field 'shipTo' on message 'PlaceOrder' (remove the references first, or force the removal)
     (run 'rumi set stacktrace on' for the full stack trace)
```

Most failures are like this one: an expected condition with a message that already tells you what to do. The stack trace is diagnostic detail that gets in the way of reading it.

Turn `stacktrace` on when you are diagnosing a genuine defect, or when you have been asked for the full trace in a support request:

```bash
$ rumi set stacktrace on
$ rumi dev entity remove processor -n Address -a /path/to/app
java.lang.IllegalStateException: cannot remove entity 'Address': still referenced by ...
        at com.neeve.appbuilder.EntityEditor.removeEntity(EntityEditor.java:...)
        ...
```

## Where Settings Are Stored

Settings live in a per-user file:

```
~/.nvx/rumi-cli/settings.properties
```

Set the `NVX_HOME` environment variable to relocate the base directory, in which case the file is `$NVX_HOME/rumi-cli/settings.properties`. This is useful in CI, where you may want settings isolated per job.

The file is plain Java properties and safe to read or edit by hand:

```properties
#Rumi CLI settings
stacktrace=off
```

If the file is missing or unreadable, every setting falls back to its default and commands run normally.

{% hint style="info" %}
Settings are deliberately **not** stored in the CLI installation directory. That directory is commonly root-owned, so `rumi set` could not write to it, and it is replaced wholesale on upgrade, which would discard your preferences. `$RUMI_CLI_HOME/conf/cli.conf` is a different thing: it is install-scoped runtime configuration, such as JVM options, not user preference.
{% endhint %}

## See Also

* [version](/rumi-cli/commands/version.md) - Print the installed CLI version
* [Installation](/rumi-cli/installation.md) - Install and upgrade the CLI
* [Commands](/rumi-cli/commands.md) - Full command reference